Deployment

Lovable Env Vars Vanish on Deploy? Fix the Vanishing Env-Var Before Your Login Breaks

If your Lovable app works in the editor but breaks once deployed — blank screen, a supabaseUrl is required error, or a login that redirects to localhost — your environment variables did not vanish. They were never set on the host. The editor injects its own values at preview time; your external host starts with an empty environment until you add them. The fix is in two places: the host's env panel and your Supabase Auth URL settings.

Get emergency help See the fix-it service

By Founder Name · Last verified: 2026-06-25

Why do my Lovable env variables disappear when I deploy?

They do not disappear — they were never present on the host. The Lovable editor injects VITE_SUPABASE_URL and your anon key into the preview sandbox automatically, so your app appears configured. When you deploy to an external host like Vercel or Netlify, that host starts with a completely empty environment. Vite bakes env vars in at build time, so a missing variable means the build ships with undefined where your Supabase URL should be.

This pattern is common enough that we have a name for it: The Vanishing Env-Var. The variable looks present everywhere you check inside Lovable, so the absence is invisible until the production build runs against a host that never received it. Because Vite resolves import.meta.env.VITE_SUPABASE_URL at build time and not at runtime, there is no way to patch it after the fact — the value is already compiled into your bundle as undefined.

The two values that vanish most often are VITE_SUPABASE_URL and VITE_SUPABASE_ANON_KEY. When either is missing, the Supabase client cannot initialise and throws supabaseUrl is required, which usually surfaces as a blank white screen the instant a real user loads the deployed site.

Vite only exposes variables prefixed with VITE_ to your client bundle. A variable named SUPABASE_URL (no VITE_ prefix) will be silently stripped from the browser build even if you set it on the host. The prefix is mandatory.

Why does my login redirect to localhost after deploying?

Because your Supabase Auth Site URL is still set to http://localhost:3000 — the value Lovable used during local preview. Supabase builds the magic-link and OAuth redirect from the Site URL configured in your project's Auth settings, not from the domain the request came from. So after sign-in, Supabase sends the user back to localhost, which their browser cannot reach, and the session silently fails to establish.

This is the second half of The Vanishing Env-Var, and it is the one that confuses people most: the env vars can be perfectly set on the host, the app loads, but authentication still breaks because the redirect target lives in Supabase's dashboard, not in your code or your host panel. You have to fix both places.

If you see the login complete, the URL flash your real domain, then bounce to localhost or a blank page, the Site URL and Redirect URLs in Supabase Auth are the culprit. Add your production domain to both fields and the loop clears.

Where exactly do I add the missing env vars on my host?

In your host's environment-variables panel, before you trigger the build that ships to production. Each host has its own location, but the rule is identical everywhere: add VITE_SUPABASE_URL and VITE_SUPABASE_ANON_KEY with the exact values from your Lovable or Supabase project, then redeploy so the build picks them up. Editing env vars never updates an already-built deployment — you must trigger a fresh build.

Copy the two values from Supabase: open your project, go to Project Settings, then API. Copy the Project URL (this is VITE_SUPABASE_URL) and the anon public key (this is VITE_SUPABASE_ANON_KEY).
Open your host's env panel — Vercel: Project Settings, then Environment Variables. Netlify: Site configuration, then Environment variables. Cloudflare Pages: Settings, then Variables and Secrets.
Add VITE_SUPABASE_URL and paste the Project URL. Add VITE_SUPABASE_ANON_KEY and paste the anon key. Use the exact VITE_ prefix — no spaces, no quotes around the value.
Set the environment scope to Production (and Preview, if you use preview deploys) so the variables apply to the build that users actually hit.
Trigger a fresh deploy. On Vercel, redeploy without the build cache; on Netlify, clear cache and deploy site. Env-var changes only take effect on the next build, never the current one.

What NOT to do: do not paste your Supabase service_role key into a VITE_ variable. The anon key is the only one safe to ship in a browser bundle. The service_role key bypasses Row Level Security entirely — exposing it in client code is a full data breach. Use the anon public key for VITE_SUPABASE_ANON_KEY, always.

How do I stop the login from redirecting to localhost?

Set your production domain as the Site URL and add it to the Redirect URLs allow-list in Supabase Auth. The Site URL is the default redirect target; the Redirect URLs list is the set of destinations Supabase will permit. Until your real domain appears in both, every sign-in falls back to localhost and the session never completes on the live site.

Open your Supabase project, go to Authentication, then URL Configuration.
Set Site URL to your production domain, for example https://yourapp.com — not localhost, and not the Lovable preview URL.
Under Redirect URLs, add https://yourapp.com/** (the wildcard allows any sub-path callback). If you use a custom auth callback route, add that exact path too.
If you still test locally, keep http://localhost:3000/** in the Redirect URLs list as well — both can coexist; only the Site URL is the single default.
Save, then sign out fully and sign in again on the production site to confirm the redirect lands on your domain and the session persists.

How can I tell which environment variable is actually missing?

Open the deployed site, press F12 for DevTools, and read the Console tab. The error string names the failure precisely: supabaseUrl is required means VITE_SUPABASE_URL is undefined in the build; an Invalid API key error from Supabase means the anon key is wrong or missing; a redirect to localhost means the Auth Site URL is unfixed. Match the symptom to the table below before changing anything.

The Vanishing Env-Var — Symptom-to-Fix Map
Symptom on deployed site	Root cause	Where to fix it
Blank white screen, console: supabaseUrl is required	VITE_SUPABASE_URL undefined in production build	Host env panel — add VITE_SUPABASE_URL, redeploy
Console: Invalid API key / 401 from Supabase	VITE_SUPABASE_ANON_KEY missing or wrong value	Host env panel — paste correct anon public key, redeploy
Login completes then redirects to localhost	Supabase Auth Site URL still set to localhost	Supabase: Authentication, then URL Configuration
OAuth/magic-link returns redirect_uri error	Production domain not in Redirect URLs allow-list	Supabase: add https://yourdomain.com/** to Redirect URLs
Var set on host but still undefined in browser	Missing VITE_ prefix — Vite stripped it from the bundle	Rename to VITE_*, redeploy with cache cleared
Worked, then broke after I edited env vars	Change saved but no fresh build was triggered	Trigger a new deploy — env changes need a rebuild
Data reads/writes 403 after env vars fixed	Separate issue: Row Level Security policy, not env vars	See RLS permissions guide, not the env panel

Why did it work before and break only after I changed hosts or redeployed?

Because the Lovable preview and your external host are two different environments that never shared state. As long as you stayed inside Lovable's hosting, the editor's injected env vars kept the app alive. The moment you connected a custom domain, exported to Vercel or Netlify, or migrated off Lovable, you moved to an environment that started empty. Nothing broke — the missing config simply became visible.

This is closely related to The Stale-Commit Deploy: a deploy that ships an older or differently-configured build than the one you tested. If you changed env vars and the site still shows the old error, your host likely served a cached build. Clearing the build cache and redeploying forces it to pick up the new environment.

If you are migrating off Lovable to your own host and want the env and auth config moved cleanly the first time, our team handles the full handoff so the deploy works on the first build instead of the fifth.

How do I verify the fix before I call it done?

Run a short verification sequence on the deployed site, not the editor preview. The most common false-positive is a fix that looks right in Lovable but still breaks for real users, because the editor still has its injected vars. Test the live domain in a fresh browser session to confirm both the env vars and the auth redirect are genuinely resolved.

Open the production domain in an incognito window so no cached session masks the problem.
Open DevTools (F12), load the site, and confirm there are zero red console errors and no supabaseUrl is required message.
Sign in with a real account and confirm the redirect lands on your domain — not localhost — and the session persists on refresh.
Trigger one authenticated data read and one write, and confirm both succeed in the Supabase table editor.
If anything still fails, check the host's deploy log to confirm the build that shipped is the one that included your env-var changes.

If env vars are set correctly and auth works but data calls return 403, your problem is no longer env-related — it is a Row Level Security policy. That is a separate fix in the backend cluster, not the deployment panel.

When should I stop and bring in an engineer to fix the deploy?

If you have added the env vars, fixed the Supabase Site URL, redeployed with the cache cleared, and the build still ships broken, the root cause is structural — a build-pipeline config, a wrong key environment, or a deploy serving a stale commit. At that point another redeploy will not help. A senior engineer can read the actual build log, confirm exactly which value the bundle compiled, and ship a working deploy without further guessing.

Signs it is time to escalate: the same error persists after three clean redeploys; env vars read correctly in the host panel but the bundle still has undefined; or you have a custom domain, edge functions, and Supabase auth all in play and cannot isolate which layer is failing. Getting a specialist in early is almost always cheaper than days of redeploy roulette.

Our Lovable app rescue service does emergency deploy fixes: we diagnose the exact missing or misconfigured value, restore a working production build, and leave you with a written record of every env var and auth URL so the next deploy is reproducible.

Fix or migrate? Answer 3 quick questions.

Question 1 of 3

Is your app down or broken right now?

Frequently asked questions

Why do my env variables work in the Lovable editor but not after I deploy?

The Lovable editor injects VITE_SUPABASE_URL and the anon key into its preview sandbox automatically, so the app looks configured. Your external host — Vercel, Netlify, Cloudflare — starts with an empty environment and never received those values. Add VITE_SUPABASE_URL and VITE_SUPABASE_ANON_KEY to the host's env panel, then redeploy so the build compiles them in.

My deployed Lovable app shows a blank screen and supabaseUrl is required — how do I fix it?

That error means the Supabase client initialised without VITE_SUPABASE_URL, which means the variable is undefined in your production build. Copy the Project URL from Supabase Project Settings, then API. Add it as VITE_SUPABASE_URL in your host's environment panel, set the scope to Production, and trigger a fresh deploy. The value is baked in at build time, so a redeploy is required.

Why does my login redirect to localhost after I deploy?

Your Supabase Auth Site URL is still set to http://localhost:3000 from local development. Supabase builds the post-login redirect from that Site URL, not from the domain the request came from. Open Supabase Authentication, then URL Configuration, set Site URL to your production domain, and add it to the Redirect URLs list. Sign out and back in to confirm the redirect lands on your real site.

Do I need the VITE_ prefix on my Lovable environment variables?

Yes. Vite only exposes variables prefixed with VITE_ to the browser bundle and silently strips everything else for security. A variable named SUPABASE_URL without the prefix will be undefined in your client code even if you set it on the host. Always use VITE_SUPABASE_URL and VITE_SUPABASE_ANON_KEY exactly, with no spaces or surrounding quotes around the value.

I changed my env vars but the site still shows the old error — why?

Editing environment variables never updates an already-built deployment. Vite compiles env values into the bundle at build time, so the live site keeps serving the old build until you trigger a new one. Redeploy with the build cache cleared — on Vercel redeploy without cache, on Netlify use clear cache and deploy site — so the fresh build picks up your updated variables.

Which Supabase key do I put in VITE_SUPABASE_ANON_KEY — anon or service_role?

Always the anon public key, never the service_role key. The anon key is designed to ship in a browser bundle and is constrained by your Row Level Security policies. The service_role key bypasses RLS entirely, so exposing it in client code is a full data breach. Copy the anon public key from Project Settings, then API, into VITE_SUPABASE_ANON_KEY.

Where do I add environment variables on Vercel, Netlify, and Cloudflare?

On Vercel: Project Settings, then Environment Variables. On Netlify: Site configuration, then Environment variables. On Cloudflare Pages: Settings, then Variables and Secrets. In every case, add VITE_SUPABASE_URL and VITE_SUPABASE_ANON_KEY, scope them to Production, and redeploy. The variables only take effect on the next build, not the deployment that is already live.

My env vars are correct but data reads now return 403 — is that still an env-var problem?

No. If the app loads, auth works, and your env vars are confirmed set, a 403 on data is almost always a Row Level Security policy blocking the request, not a missing variable. That is a backend fix in your Supabase policies, not the deployment panel. See our guide on Supabase RLS and permission errors to write the policy that lets authenticated users read their rows.

Could the wrong anon key cause an Invalid API key error after deploy?

Yes. If VITE_SUPABASE_ANON_KEY is missing, truncated, or copied from a different Supabase project, the client sends an invalid key and Supabase returns Invalid API key or a 401. Re-copy the anon public key from Project Settings, then API of the correct project, paste it with no trailing spaces, and redeploy. Confirm in DevTools that the network request now carries the right key.

I have tried everything and the deploy still ships broken — can someone just fix it?

Yes. If env vars read correctly in the host panel but the bundle still compiles undefined, or the same error survives three clean redeploys, the root cause is structural and another redeploy will not help. Book an urgent deploy fix — we read the actual build log, confirm exactly which value shipped, and restore a working production build, then document every env var and auth URL so the next deploy is reproducible.

Keep reading

App down or leaking data? Get an expert on it within 24–48h.

Book a free 30-minute audit call. We'll diagnose what's wrong and tell you exactly what it costs to fix.

Get emergency help