Feature Flags Get First-Class Treatment in Vercel

Feature flags let teams ship changes incrementally, test in production, and decouple deployment from release. Vercel has been steadily improving how those flags work inside its platform, and the latest updates bring deeper integrations with observability tools, an experimental Next.js pattern for server-side experimentation, and a more streamlined way to manage overrides from the toolbar.

The integration story begins with Edge Config, which lets you load flags at the edge without an extra network hop — reportedly at least twice as fast as fetching them directly from a flag provider. From there, the Vercel Toolbar added the ability to override flag values per session, storing those overrides in an optionally encrypted cookie. This avoids switching between browser tabs and external dashboards for minor adjustments, a workflow already adopted by teams like Notion and Leonardo.Ai.

Version control also enters the picture, with the toolbar now recommending branch-based overrides so preview deployments can reflect the right experiment state. A teammate working on a branch locally, or reviewing it via a Preview Deployment, can see suggested flag states that match the code under test. Onboarding for connecting flags to the toolbar has been improved alongside that change.

Flags in Your Analytics and Logs

Flag values are no longer isolated from your other telemetry. In beta, data from flags is now exposed in Vercel Web Analytics and Runtime Logs.

In Web Analytics, page views and custom events can be filtered or broken down by flag state. That makes it possible to measure whether a specific variation actually changes user behavior, regardless of which provider is defining the flag. Runtime Logs gain similar context, attaching the active flag values to each log line so that when an error appears, you can see whether it happened under an experiment or a control group. The integration also feeds into Speed Insights, with a coming capability to toggle a flag in production and see the impact on Web Vitals in real time.

Precomputed Flags for Server-Side Experimentation

Client-side feature flag implementations inherit a set of well-known problems: loading spinners, the wrong variant flashing before replacement, layout shifts — collectively referred to as jank. Vercel's position is that server-side experimentation avoids these issues, and the company is pursuing that approach with a new package: @vercel/flags/next.

The SDK is split into two entry points:

  • @vercel/flags/react: helper functions to integrate with the toolbar and platform
  • @vercel/flags/next: implements Vercel’s flags patterns for Next.js

Flags are declared as code with their own metadata rather than as opaque provider values. This design pattern encodes Vercel's best practices for routing and evaluation.

Of particular note is an experimental pattern the team calls precomputing flags. Instead of evaluating flags in the browser, Middleware determines the flag values for a given request and routes the user to a prerendered page tailored to their experiment group. Because results are chosen ahead of rendering, this works even when multiple flags — or multiple experiments — apply to the same page, while avoiding layout shifts, flicker, and skewed experiment data.

A SvelteKit implementation is in the works. Public documentation and an example repository are available for developers who want to try the Next.js pattern and provide early feedback.