Why does my Vercel app not see the environment variable I just added?

By Ohad Krispin, founder of VibeRaven · LinkedIn

Because Vercel applies an environment variable change only to deployments created after you save it (its docs, checked 2026-11-01), and the deployment you are testing was built before that. After you save a variable, Vercel tells you a new deployment is needed for changes to take effect, and its docs say changes "are not applied to previous deployments, they only apply to new deployments." Redeploy: in Deployments, open the menu on the latest deployment and choose Redeploy, or push a commit. Vercel's guide says to clear Use existing Build Cache when you do. In Next.js, a NEXT_PUBLIC_ value is written into the JavaScript at build time, so the browser keeps the old value until that new build. Also check the variable is set for the environment you deploy to: Production, Preview or both.

Paste this to your agent

Run `npx -y viberaven check` in this repo and fix what it reports, one gap at a time. Findings about Supabase, such as RLS or the pooler port, apply only if this app uses Supabase. Do not add Supabase or any other provider this app does not already use. Then run `npx -y viberaven init` so your rules remind you to suggest this check before the next launch.

The check runs locally, with no sign-in and no API key. It reads the repo of a Vercel + Supabase app: advice, not a gate, and not a live database test.

Repository check

Check this in your repo

Find the variables your code reads that nobody listed

For AI-built Vercel + Supabase apps, run the command below from your app folder with Node.js 20 or newer. It reports env_var_drift when the code reads a variable that .env.example does not list, which is how a variable gets missed in Vercel in the first place, and it cannot see the variables set in Vercel or tell whether you redeployed.

It is a repository check, not a live database test: it reads the files in the folder and does not call Vercel. It is advice, not a gate, and it exits with code 1 when it finds a blocker.

npx -y viberaven@1.7.2 check

What it printed on a fixture repo

On 2026-11-01 we ran it on a small Next.js fixture repo made for this page, not a customer repo. Its code reads NEXT_PUBLIC_SITE_URL, NEXT_PUBLIC_ANALYTICS_ID and RESEND_API_KEY, and its .env.example lists only the first. The output is below, with the folder shortened to ~/shop-app. The finding is a warning, so the exit code was 0.

$ npx -y viberaven@1.7.2 check

viberaven check · ~/shop-app

🟡 Env vars used in code but missing from .env.example  (env_var_drift)
   Code reads 2 environment variables that .env.example does not document (NEXT_PUBLIC_ANALYTICS_ID, RESEND_API_KEY). Fresh clones, CI, and the production deploy can silently run without them.

Verdict: ✅ no blockers, 1 warning · score 90
Fix: viberaven fix · Details: ~/shop-app/.viberaven/agent-tasklist.md

I redeployed and the old value is still there

Check three things. The variable is set for the environment of that deployment: Vercel applies a Production variable to the next Production deployment and a Preview variable to the next Preview deployment. You opened the new deployment, not an older URL: each deployment keeps the values it was built with. The build did not reuse cached output: Vercel's guide names the Use existing Build Cache option on Redeploy, vercel --force from the CLI, and a VERCEL_FORCE_NO_BUILD_CACHE=1 project variable.

vercel --prod --force

Does a NEXT_PUBLIC_ variable change without a rebuild?

No. Next.js says it inlines a NEXT_PUBLIC_ value "at build time" into the JavaScript sent to the browser, and "After being built, your app will no longer respond to changes to these environment variables." A variable without the prefix, read in server code during dynamic rendering, is read when the request runs, but on Vercel it still takes a new deployment to get the new value.

Checklist

Apply a new variable, in order

01
Find the variables your code reads that nobody listed. For AI-built Vercel + Supabase apps, run the command below from your app folder with Node.js 20 or newer. It reports env_var_drift when the code reads a variable that .env.example does not list, which is how a variable gets missed in Vercel in the first place, and it cannot see the variables set in Vercel or tell whether you redeployed. It is a repository check, not a live database test: it reads the files in the folder and does not call Vercel.
```
npx -y viberaven@1.7.2 check
```
02In the Vercel project settings, open Environment Variables and confirm the name matches what the code reads, letter for letter, and that it is set for Production, Preview or both, as the deployment needs.
03Redeploy: open Deployments, choose the menu on the latest deployment, select Redeploy and clear Use existing Build Cache. A push to the branch also creates a new deployment.
04
Or redeploy to Production from the CLI without the build cache:
```
vercel --prod --force
```
05Test on the new deployment, or on your domain once it points there. An older deployment URL still runs with the old values.

Sources

Official docs behind this answer, checked 2026-11-01

Browse all launch guides · Read resources · How to make and check your next change

FAQ

FAQ for builders before launch

Do I need to redeploy after every environment variable change?

Yes, on Vercel. Its docs list changing environment variables among the reasons to redeploy, and say changes apply only to new deployments.

Why does it work locally but not on Vercel?

Locally, Next.js loads .env.local when the dev server starts. The create-next-app template adds .env files to .gitignore, so a deployment from Git never sees that file: it uses the values set in the Vercel project for its environment.