Using flags in Next.js

The @vercel/flags package exposes the @vercel/flags/next submodule, which implements the Feature Flags pattern.

1. Set up FLAGS_SECRET

   Run the following code in your terminal to generate a secret and save it as the FLAGS_SECRET environment variable:

   Terminal

   node -e "console.log(crypto.randomBytes(32).toString('base64url'))"

   This secret is used by the SDK to automatically read overrides set by the Vercel Toolbar.

2. Declare a feature flag

   Declare a feature flag called showSummerSale in code. The decide function can be async and is called when the feature flag is used. In this example, it always returns false, so this feature flag would always be off:

   flags.ts

   import { unstable_flag as flag } from '@vercel/flags/next';
    
   export const showSummerSale = flag({
     key: 'summer-sale',
     decide: () => false,
   });

3. Use the declared feature flag

   You can now import the flags file that you created in the previous step, and call the showSummerSale flag in code. This will run the decide function and forward its return value:

   app/page.tsx

   import { showSummerSale } from "../flags";
    
   export default async function Page() {
     const sale = await showSummerSale();
     return sale ? <p>discounted</p> : <p>regular price</p>;
   }

Feature flags can be backed by any feature flag provider or no feature flag provider at all.

In the initial implementation of decide, we always return false. However, your team members can use Vercel Toolbar to override this feature flag.

This can be particularly useful for trunk-based development, where you merge new features to the main branch frequently while keeping the feature flag off. You can still use Vercel Toolbar to create an override and try out the feature in all development environments, including production.

As the requirements for this feature flag change you might want to change it to be backed by an Environment Variable. You can then change the decide function like so:

import { unstable_flag as flag } from '@vercel/flags/next';
 
export const showSummerSale = flag({
  key: 'summer-sale',
  decide: () => process.env.SUMMER_SALE_ENABLED === '1',
});

This now allows changing the feature flag without changing code: change the environment variable and redeploy. So far the feature flag always loaded instantly, since the resolution logic is hardcoded. But the downside of this approach is that changing a feature flag will not affect any existing deployments or preview deployments of other branches.

For further iterations, the feature flag can be backed by Edge Config in order to be changed without redeploying and will affect all deployments:

import { unstable_flag as flag } from '@vercel/flags/next';
import { get } from '@vercel/edge-config';
 
export const showSummerSale = flag({
  key: 'summer-sale',
  async decide() {
    const value = await get(this.key); // this.key refers to "summer-sale"
    return value ?? false;
  },
});

Finally, you could back it by a feature flag provider:

import { unstable_flag as flag } from '@vercel/flags/next';
 
export const showSummerSale = flag({
  key: 'summer-sale',
  async decide() {
    return getLaunchDarklyClient().variation(this.key, false);
  },
});

If you set an override for this feature flag using Vercel Toolbar, then the feature flag will respect the override and will not invoke the decide function.

This approach calls reportValue whenever a feature flag is called and returns a value. This works even when a flag is overridden.

It is not possible to pass any arguments when invoking the feature flag. This constraint was introduced on purpose to ensure a consistent return value for the given feature flag throughout the whole application. Instead, if you need to get some context based on the incoming request you can manually call cookies() or headers(). You can pair this with React.cache which caches for the duration the request being handled, so you avoid fetching the same value from multiple feature flags.

Flags automatically trigger dynamic mode since they are by definition dynamic.

This is an extension to the previously described pattern. It allows middleware to precompute feature flag values, which can then be passed down to the Vercel Functions. Passing down precomputed flags can either happen by adding a header to the request or by rewriting the request to a path that includes the precomputed values.

This pattern is useful for experimentation on static pages, as it allows middleware to make routing decisions, while being able to keep the different variants of the underlying flags static.

It further allows generating a page for each combination of feature flags either at build time or lazily the first time it is accessed. It can then be cached using ISR so it does not need to be regenerated.

1. Export flags to be precomputed

   You can export one or multiple arrays of flags to be precomputed. This by itself does not do anything yet, but you will use the exported array in the next step:

   flags.ts

   import { unstable_flag as flag } from '@vercel/flags/next';
    
   export const showSummerSale = flag({
     key: 'summer-sale',
     decide: () => false,
   });
    
   export const showBanner = flag({
     key: 'banner',
     decide: () => false,
   });
    
   export const precomputeFlags = [showSummerSale, showBanner] as const;

2. Precompute flags in middleware

   In this step, import precomputeFlags from the flags file that you created in the previous step. Then, call precompute with the list of flags to be precomputed. You'll then forward the precomputation result to the underlying page using an URL rewrite:

   middleware.ts

   import { type NextRequest, NextResponse } from 'next/server';
   import { unstable_precompute as precompute } from '@vercel/flags/next';
   import { precomputeFlags } from './flags';
    
   // Note that we're running this middleware for / only, but
   // you could extend it to further pages you're experimenting on
   export const config = { matcher: ['/'] };
    
   export async function middleware(request: NextRequest) {
     // precompute returns a string encoding each flag's returned value
     const code = await precompute(precomputeFlags);
    
     // rewrites the request to include the precomputed code for this flag combination
     const nextUrl = new URL(
       `/${code}${request.nextUrl.pathname}${request.nextUrl.search}`,
       request.url,
     );
    
     return NextResponse.rewrite(nextUrl, { request });
   }

3. Accessing the precomputation result from a page

   Next, import the feature flags you created earlier, such as showBanner, while providing the code from the URL and the precomputeFlags list of flags used in the precomputation.

   When the showBanner flag is called within this component it reads the result from the precomputation, and it does not invoke the flag's decide function again:

   app/[code]/page.tsx

   import { precomputeFlags, showSummerSale, showBanner } from '../../flags';
    
   export default async function Page({ params }: { params: { code: string } }) {
     // access the precomputed result by passing params.code and precomputeFlags
     const summerSale = await showSummerSale(params.code, precomputeFlags);
     const banner = await showBanner(params.code, precomputeFlags);
    
     return (
       <div>
         {banner ? <p>welcome</p> : null}
    
         {summerSale ? (
           <p>summer sale live now</p>
         ) : (
           <p>summer sale starting soon</p>
         )}
       </div>
     );
   }

   This approach allows middleware to decide the value of feature flags and to pass the precomputation result down to the page. This approach also works with API Routes.

4. Enabling ISR (optional)

   So far you've set up middleware to decide the value of each feature flag to be precomputed and to pass the value down. In this step you can enable ISR to cache generated pages after their initial render:

   app/[code]/layout.tsx

   import type { ReactNode } from 'react';
    
   export async function generateStaticParams() {
     // returning an empty array is enough to enable ISR
     return [];
   }
    
   export default async function Layout({ children }: { children: ReactNode }) {
     return children;
   }

5. Opting into build-time rendering

   The @vercel/flags/next submodule exposes a helper function for generating pages for different combinations of flags at build time. This function is called generatePermutations and takes a list of flags and returns an array of strings representing each combination of flags:

   app/[code]/layout.tsx

   import type { ReactNode } from 'react';
   import { unstable_generatePermutations as generatePermutations } from '@vercel/flags/next';
    
   export async function generateStaticParams() {
     const codes = await generatePermutations(precomputeFlags);
     return codes.map((code) => ({ code }));
   }
    
   export default async function Layout({ children }: { children: ReactNode }) {
     return children;
   }

   You can further customize which specific combinations you want render by passing a filter function as the second argument of generatePermutations.

6. Reporting evaluated flag values

   It is also possible to use the layout file we created earlier to surface precomputed values. They will then get picked up by the Vercel Toolbar, and they can be used to annotate Web Analytics.

   app/[code]/layout.tsx

   import type { ReactNode } from 'react';
   import { precomputeFlags } from '../flags';
   import { encrypt } from '@vercel/flags';
   import { unstable_deserialize as deserialize } from '@vercel/flags/next';
   import { FlagValues } from '@vercel/flags/react';
   import { Suspense } from 'react';
    
   export async function generateStaticParams() {
     return [];
   }
    
   export default async function Layout({
     children,
     params,
   }: {
     children: ReactNode;
     params: { code: string };
   }) {
     const values = await deserialize(precomputeFlags, params.code);
    
     return (
       <>
         {children}
         <Suspense fallback={null}>
           <FlagValues values={await encrypt(values)} />
         </Suspense>
       </>
     );
   }

This approach of precomputing feature flags and using middleware to rewrite users to a statically generated version of a page eliminates layout shift, loading spinners, and flashing the wrong experiment.