Vercel env vars not working in production: 5 checks

Open the failing page or function log and find the line that reads the variable: `process.env.STRIPE_SECRET_KEY` in a server function, `import.meta.env.VITE_SUPABASE_URL` in a Vite app, `process.env.NEXT_PUBLIC_SUPABASE_URL` in Next.js browser code.

Write the name down exactly, prefix included. A local `.env` file often has the right value under a slightly different name, or under a name with no framework prefix, and that difference is invisible until production. Never paste the value itself into a ticket, chat or log while you debug; the name is enough.

To list every name the code reads at once in a Vercel + Supabase app, run `npx -y viberaven@1.7.2 check` from the project root. It reports each variable the code reads that `.env.example` does not list as `env_var_drift`. It cannot see your Vercel settings, so compare its list with `vercel env ls production`.

In Vercel, every variable is applied to one or more environments: Production, Preview, Development and any custom environments. A variable added only to Production is missing from every Preview deployment, and the reverse. A `vercel` CLI deploy without `--prod` is a Preview deployment, so it reads the Preview values.

Preview variables can apply to all non-production branches or to one branch. A branch-specific value overrides the general Preview value with the same name, so a branch can see a different value from the rest of your previews.

Open the deployment that fails, note whether it is Production or Preview and which branch built it, then open Settings, Environment Variables and confirm the exact name is set for that environment.

Browser code cannot read server environment variables at runtime. Frameworks copy prefixed variables into the browser bundle during the build: `VITE_` in Vite and `NEXT_PUBLIC_` in Next.js. If the variable was missing when that build ran, the bundle carries `undefined` until you build again.

Server functions read `process.env` when they run, inside one deployment, so they see the variables that deployment was created with. In Next.js, a statically rendered page runs its server code during the build, so it shows the value from that build; dynamic rendering reads it per request.

Prefixed variables end up in public JavaScript. Use a prefix only for a value that is safe in the browser, such as a Supabase URL or publishable key. A service role key, Stripe secret key or webhook secret belongs in server code, without a public prefix.

Vercel applies environment variable changes to new deployments only. Adding or editing a variable does not change the deployment that is already live.

After the fix, push a commit or redeploy from the Vercel dashboard, and open the URL of that new deployment, not an older preview link. For a prefixed browser variable, the new deployment must include a new build.

Two dashboard actions behave differently. Promote to Production on a preview rebuilds it with the Production values. Instant Rollback does not rebuild: it points your domains at an older deployment, which keeps the values it was built with.

Seeing the variable in the dashboard proves it is configured. It does not prove that the code reads it, that this deployment has it or that the value is correct. Test the behavior that failed on the new deployment: sign in, load the data or trigger the payment flow with test data.

For a server value, check the function log for the error you started with. For a browser value, open the deployed page and confirm the request goes to the expected host. If the same flow also uses a callback URL, such as OAuth or a webhook, check that it points to this deployment's domain.

Vercel keeps one set of values per environment, and a deployment reads only the set for the environment that created it. The same name can hold a different value in each, which is the usual way to give previews a test database or Stripe test keys.

Vercel says you cannot use Preview values in a production deployment: promoting a preview switches it to the Production values. Development values never reach a deployment; they exist for your machine.

Next.js replaces `process.env.NEXT_PUBLIC_NAME` with its value when `next build` runs and inlines it into the JavaScript sent to the browser. If the name was not set for the environment that ran that build, the bundle keeps `undefined`, and setting the variable later changes nothing until a new build.

Only a direct reference is replaced. A dynamic lookup such as `process.env[name]`, or reading it through `const env = process.env`, is not inlined, so the browser gets nothing. Vite also replaces `import.meta.env.VITE_NAME` at build time, so the same rebuild rule applies. If a public value must change without a rebuild, Next.js suggests serving it from your own API instead.

`vercel env pull .env.local` writes your project's Development values to a local file. Add `--environment=preview` for the Preview values and `--git-branch=<branch>` for a branch override. Run it again after every change in Vercel, because the file does not update itself. `vercel env ls production` lists the names set for Production.

Values of the Secret type cannot be read back, and the Vercel CLI stores Production and Preview variables as Secret by default. For a secret your local file does not already hold, a pull writes a placeholder. To run a production build with the Production values without writing them to disk, use `vercel env run -e production -- next build`.

On October 14, 2026 a preview deployment of this website showed "Managed sign-in is not configured in this environment" and reported that the Supabase values were not included in the build. The app reads `VITE_SUPABASE_URL` and `VITE_SUPABASE_ANON_KEY` at build time, and that preview had been built without them.

The fix follows the steps above: set both names for the Preview environment, then build a new preview. At the time of writing that preview had not been rebuilt, so this case is an observed failure, not a verified repair.

Give your agent the failing route and the deployment environment, without secret values. For a Vercel + Supabase repo, the existing VibeRaven Skill linked below provides a repository pass for environment names and supported exposure findings. The task below keeps that evidence separate from the settings and deployment you must verify in Vercel.

For apps on Vercel + Supabase, VibeRaven reads the repository and lists variables the code reads that `.env.example` does not list. It cannot see which variables are set in your Vercel project or which deployment is live, so steps 2, 4 and 5 still happen in Vercel and in your app. It is advice, not a gate, and a repository check, not a live database test.