Vercel Flags: Platform-native feature flags

At Vercel, feature flags are how we ship. From new features to model updates in v0, and even infrastructure changes like a production database migration where a flag was the cutover. The v0 team alone runs hundreds at any given moment.

Merging code sends a build to production, but the feature flags control whether users can see what changed. Flags let you ship on your own schedule, release to segments when you're ready, and roll back by immediately by toggling a flag, without touching source files or redeploying.

Vercel Flags is platform-native: server-side by default, zero impact on page performance, and directly integrated with the frameworks you already use.

Link to headingWhat is Vercel Flags

Vercel Flags lets you create feature flags, define targeting rules by user attributes, segments, or environment, run progressive rollouts, and flip kill switches if something breaks in production.

From your code, you read flags through Flags SDK, an open-source, provider-agnostic library we maintain with first-class adapters for Next.js and SvelteKit. If you are using another framework, you can consume Vercel Flags using the built-in OpenFeature provider.

The Vercel Flags dashboard sits alongside your project and deployments, where you can create and manage flags.

But what makes Vercel Flags different from other flag services is the framework integration.

Link to headingWhy framework-native matters

Other flag providers give you a generic SDK to wire through your framework yourself, and a separate dashboard to manage flags in. Vercel Flags is built into the Vercel platform, so you manage flags in the same dashboard as your deployments, and your code reads them through the framework-native Flags SDK.

Link to headingServer-side evaluation

When a flag is evaluated on the client, users see a loader, a flicker, or a layout shift. The browser can't render the correct view until the flag value comes back. The Flags SDK evaluates on the server instead. With Next.js React Server Components, you read the flag with await during render. The correct view is determined server-side and the browser renders it directly, with no separate flag request. That value comes from Vercel Flags, where a configuration change propagates to every region within milliseconds.

1
import { showNewFeature } from "@/flags"
2

3
export default async function Page() {
4
  const isEnabled = await showNewFeature()
5
  return isEnabled ? <NewDashboard /> : <OldDashboard />
6
}

For advanced cases, you can pass the flag as a promise to a client component rather than awaiting it. This lets the page start rendering before the flag value arrives, with the component showing a fallback in the meantime. The flag still resolves on the server, so there is no browser-side request for it.

Link to headingAutomatic flag registration

Vercel Flags registers flags automatically. Define one in code, deploy, and it appears in the dashboard as a draft. Promote the draft when you're ready to configure targeting and roll out. Remove the flag from your code and the dashboard marks it as unreferenced, so you always know what's safe to archive. The flags you write are the flags you manage, with no separate list to keep in sync by hand.

1
import { flag } from "flags/next"
2
import { vercelAdapter } from "@flags-sdk/vercel"
3

4
export const showNewFeature = flag({
5
  key: "show-new-feature",
6
  adapter: vercelAdapter()
7
})

Link to headingPrecompute

Static pages are fast and consistent because they are served from the CDN regions closest to you and your users. But adding a flag makes a page dynamic. Either you render server-side and lose CDN delivery, or you fetch the flag client-side and get layout shift back. However, Flags SDK comes with an optional, advanced pattern that solves this. Precompute lets you build all variants at build time, distribute them through the CDN, and have Routing Middleware (the proxy.ts file in Next.js) route each user to the right one. Every page stays static and loads with no layout shift.

Link to headingAgent-native flag management

The vercel flags CLI exposes the same flag management from your terminal, so you and your coding agents can create flags, configure targeting, run rollouts, and archive them.

Link to headingOverriding flags in the browser

Flags Explorer, built into the Vercel Toolbar, lets you override any flag in your browser session to test a variant. The shared configuration stays untouched and you do not redeploy.

Link to headingVercel ships on Vercel Flags

While we made Vercel Flags generally available in April 2026, we've been using it internally for over a year. The v0 team is a good example of what this looks like at scale, with hundreds of flags active at any given moment.

Here are some examples of what teams put behind flags:

• New features under development

• AI model routing per user or segment

• Operational kill switches

• Database migrations and provider swaps

• Beta access for early customers or internal teams

For a product like v0, any added latency degrades the end-user experience. Because Vercel Flags evaluates server-side, the team gets feature flagging without the additional round trip that client-side flag evaluation adds.

Because every new feature is built behind a flag, developers can merge to main continuously without releasing unfinished work. There are no long-lived branches and no painful merge conflicts to resolve. Deploying code and releasing a feature become two separate decisions.

A release moves through a controlled progression. The developer who built the feature sees it first, then the internal team. After that, the flag steps up through 5%, 10%, 25%, and 50% of users for six hours each, before going to everyone. If something goes wrong at any stage, the team can kill the feature without making a code change or redeploying.

Flags also control v0's AI model traffic, shifting gradually when a new model launches rather than cutting over all at once.

v0 even ran a production database migration with a flag. We kept the old and new databases in sync, and the flag controlled which database was in use. Flipping the flag was the cutover itself. We rehearsed it in staging repeatedly, then ran it in production without degrading traffic. The flag turned a high-stakes infrastructure change into something the team could practice, schedule, and ship with confidence.

Link to headingGet started

Once shipping code and releasing a feature are separate stages, you can start to just ship things with a level of confidence that you couldn't get from PRs alone.

Vercel Flags is available on every plan. The vercel flags CLI allows you and your agents to create, inspect, manage rollouts, and archive flags from anywhere.

Read the Vercel Flags documentation to get started, or ask your agent for help with the Flags SDK skill.