Feature flags without the performance tax
Feature flags have become the standard mechanism for decoupling deployment from release. At Vercel, they're used for everything from new product features and AI model updates in v0 to infrastructure changes like database migrations. The v0 team alone typically has hundreds of flags active at once, each one serving as a control point that makes shipping continuous and rollbacks instant.
The core idea is straightforward: merging code triggers a production build, but flags determine what users actually see. This lets teams ship on their own schedule, target specific segments, and disable a feature immediately without touching source files or redeploying. Vercel Flags takes this further by making the flag system platform-native, which means flag evaluation happens server-side by default with zero added page latency, and it integrates directly with the frameworks teams already use.
Managing flags alongside deployments
Vercel Flags provides the expected toolkit: create flags, define targeting rules by user attributes, segments, or environment, run progressive rollouts, and maintain kill switches for production incidents. The dashboard for managing all of this sits alongside your project and deployments rather than in a separate service. From code, flags are read through the open-source, provider-agnostic Flags SDK, which ships with first-class adapters for Next.js and SvelteKit. If you're on another framework, a built-in OpenFeature provider is available.
What distinguishes this from other flag providers is the depth of framework integration. Most providers hand you a generic SDK to wire in yourself plus a separate dashboard to maintain. Here, flag management, evaluation, and deployment tooling live in the same platform.
Server-side evaluation by default
Client-side flag evaluation is a UX liability: the browser can't render the correct view until the flag value returns, which means loaders, flicker, and layout shifts. The Flags SDK avoids this by evaluating on the server. In Next.js React Server Components, you read a flag with await during render, which is asynchronous but doesn't introduce a separate round trip. The correct variant is determined server-side and the browser renders it immediately. Flag configuration changes propagate to every region in milliseconds via the Vercel platform.
import { showNewFeature } from "@/flags"
export default async function Page() {
const isEnabled = await showNewFeature()
return isEnabled ? <NewDashboard /> : <OldDashboard />
}
For more advanced cases, Flags SDK supports passing the flag as a promise to a client component instead of awaiting it on the server. This lets the page begin rendering before the flag resolves, with the component displaying a fallback in the interim, and still conducts no browser-side request for the flag.
Flags that register themselves
A common source of drift is keeping flag definitions in code synchronized with a separate management console. Vercel Flags removes that maintenance burden: define a flag in code, deploy, and it registers itself in the dashboard as a draft. Promote the draft when you're ready to configure targeting and rollout. Delete the flag from code and the dashboard marks it unreferenced, so you always know what's safe to archive. The flags you write are the only flags you manage.
import { flag } from "flags/next"
import { vercelAdapter } from "@flags-sdk/vercel"
export const showNewFeature = flag({
key: "show-new-feature",
adapter: vercelAdapter()
})
Precompute for fully static pages
Static pages are fast because they're served from edge CDNs, but a flag typically forces a page into dynamic rendering. You can render server-side (losing CDN delivery) or fetch client-side (reintroducing layout shift). Flags SDK's optional precompute pattern avoids both: build every variant at build time, distribute them over the CDN, and let the Routing Middleware (proxy.ts in Next.js) route each user to the correct version. This keeps every page static with zero layout shift, though Vercel notes it is an advanced pattern and points teams to the docs for implementation details.
Flags from the terminal and browser
The vercel flags CLI exposes the same flag management from the command line, enabling developers and coding agents to create flags, configure targeting, run rollouts, and archive them without opening the dashboard. On the testing side, Flags Explorer is built into the Vercel Toolbar and lets you override any flag per browser session to test variants. The shared configuration remains untouched, and no redeploy is needed.
Real-world usage: v0's rollout pipeline
Vercel makes its internal usage of Vercel Flags a case study in progressive delivery. While the platform reached general availability in April 2026, it had been in production internally for over a year. For v0, the stakes are latency-sensitive: because flags evaluate server-side, teams get feature flagging without the extra client-side round trip.
Every new feature at v0 ships behind a flag, which means developers merge to main continuously without exposing unfinished work. The workflow avoids long-lived branches and the resulting merge conflicts. Deploying code and releasing a feature become separate, decoupled decisions. A typical release follows a progression: the originating developer sees the feature first, then internal staff, then it steps through 5%, 10%, 25%, and 50% of users, holding each stage for six hours before reaching everyone. If metrics go sideways, the kill switch is a flag toggle rather than an emergency code change.
Flags don't just gate new product code. v0 also uses them for AI model traffic, shifting user requests gradually when a new model launches instead of cutting over all users at once. The most dramatic example, though, was a production database migration. Old and new databases were kept in sync while a flag controlled which one each request hit. The team rehearsed the migration repeatedly in staging, then performed the production cutover by running the same process. Because infrastructure operations and code deployments follow the same flag-based control loop, even a high-stakes migration becomes a rehearsable, schedulable change.
The practical upshot across all of this usage is a development culture where shipping continuously and releasing deliberately are two separate stages, each with its own controls. Vercel Flags is available on every plan, with the vercel flags CLI enabling management from any terminal. Details are in the Vercel Flags documentation, and a Flags SDK skill is available for agent-assisted setup.
