Lovable Site Down With "Missing Supabase Environment Variables": What Changed and the Fix

On the afternoon of August 20, three builders showed up in the Lovable Discord within a few hours of each other with the exact same story. Published site down. Preview down. The error page just says "This page didn't load. Something went wrong on our end." And the part that made everyone doubt their sanity: reverting to a version that worked that same morning changed nothing.

The status page stayed green the whole time.

I spent the afternoon connecting the three cases, and by the evening one of them got us the console log that explained everything. This post is what we found, how to fix it if it hits you, and what I think is happening underneath.

What happened, in one paragraph

Around August 20, Lovable's build and serving pipeline started looking for Supabase environment variables under their new names: SUPABASE_URL and SUPABASE_PUBLISHABLE_KEY, the convention of the TanStack Start stack and of Supabase's newer key naming. Existing projects still store those same values under the legacy Vite names: VITE_SUPABASE_URL and VITE_SUPABASE_ANON_KEY. Nobody's stored secrets were migrated, and nothing was announced. So the first rebuild after the change came out of the oven asking for names that do not exist in your project, and the site died on boot.

You are in the blast radius if both of these are true:

• Your project migrated from the classic (Vite) stack to TanStack Start at some point, even weeks ago and even if everything worked fine since. At least one affected project suggests exposure may be wider than that, so do not rule yourself out on this point alone.
• Your site got rebuilt or re-served after the change: a publish, a revert-and-republish, or platform-side re-serving with no action from you at all.

That second point is the key. The trigger is the rebuild, not anything you did to your code. That is why sites that worked in the morning died in the afternoon with zero changes from their builders.

The error

On the surface, the published site or the preview shows the generic Lovable error page. Nothing in the editor looks wrong. The project says completed, the agent is done, there are no build errors.

The console tells the real story:

Missing Supabase environment variable(s): SUPABASE_URL, SUPABASE_PUBLISHABLE_KEY.
Connect Supabase in Lovable Cloud.

Here is the thing. The project HAS its Supabase variables set. They are just named differently:

What the project has (older convention)	What the runtime now wants (newer convention)
VITE_SUPABASE_URL	SUPABASE_URL
VITE_SUPABASE_ANON_KEY	SUPABASE_PUBLISHABLE_KEY

The VITE_ prefix comes from the classic Vite stack, where variables get baked into the client bundle at build time. The new names come from the TanStack stack, which reads them server side, plus Supabase's own newer key naming, where "publishable" replaces "anon". Same values, different labels. The app boots, looks for the new names, finds nothing, and dies before rendering a single pixel.

Do not follow the error's advice. The error says "Connect Supabase in Lovable Cloud" even if your project uses your own external Supabase. One of the three affected projects was exactly that, a self-managed Supabase, correctly connected, working for months. Your setup is fine. The message is part of the bug.

Why reverting does not save you

This is the cruel part, and it teaches something worth keeping even after this incident is fixed.

Your environment variables do not live in your code history. Reverting rolls back your code, not your project configuration. And republishing a reverted version forces a rebuild with the current toolchain, so even old code comes out of the oven expecting the new variable names. That is how a build that genuinely worked in the morning can die in the afternoon with zero changes on your side, and stay dead through every revert you try.

If you remember one thing: when a site breaks and reverting does not fix it, stop reverting. The problem is almost never in your code history. Look at configuration, environment, or the platform itself.

The fix

Two paths, fastest first:

1. Duplicate the variables under the new names. In your project's env/secrets settings, add SUPABASE_URL with the same value as VITE_SUPABASE_URL, and SUPABASE_PUBLISHABLE_KEY with the same value as VITE_SUPABASE_ANON_KEY (yes, the publishable key is your anon key). Republish. You are not replacing anything, just making the same values findable under both names.
2. Code-level alternative. Ask the agent to update src/integrations/supabase/client.ts to read your existing VITE_ variables again. Cleaner in one sense, but it touches code and costs credits.

If you go the agent route, paste exactly this. The three "do not" lines at the end are what keep the agent from wandering off into a credit-burning loop:

My site shows: "Missing Supabase environment variable(s):
SUPABASE_URL, SUPABASE_PUBLISHABLE_KEY". The variables exist
under VITE_SUPABASE_URL and VITE_SUPABASE_ANON_KEY. Update
src/integrations/supabase/client.ts to read the existing VITE_
variables. Do not create new variables, do not connect Lovable
Cloud, do not change anything else.

If the settings screen refuses to accept variable names without the VITE_ prefix, that is the platform blocking you, and it belongs in a support ticket at lovable.dev/support with your project ID. Mention that multiple projects hit this on August 20, it helps the team connect the dots.

What I think is happening

To be clear about what is confirmed and what is hypothesis. Confirmed: the exact error, three independent projects, revert not fixing it, and the naming mismatch in at least one console log. Hypothesis territory: why now.

The evidence points to a platform-side change in the build or serving pipeline that started expecting the new variable names without migrating the secrets stored in existing projects. A build that ran fine in the morning under the old convention got rebuilt or reserved under the new one in the afternoon. Projects that migrated from classic to the TanStack stack are clearly in the blast radius, but at least one affected project gives us reason to believe any rebuild after the change could be exposed, migrated or not.

If that reading is right, the real fix is on Lovable's side: map the legacy names automatically so nobody's production app dies over a label. I have reported it with project IDs and evidence. In the meantime, the duplicate-the-secrets fix above is your bridge.

Quick answers

Why is my Lovable site suddenly down when I changed nothing? If the console shows "Missing Supabase environment variable(s)", your project stores its Supabase config under the legacy VITE_ names and the runtime now looks for SUPABASE_URL and SUPABASE_PUBLISHABLE_KEY. Duplicate the values under the new names and republish.

Does reverting to an older version fix it? No. Environment variables live outside your code history, so a revert rolls back code but not configuration, and republishing rebuilds with the current toolchain either way.

The error says "Connect Supabase in Lovable Cloud". Should I? Not if your Supabase is already connected, and especially not if you use your own external Supabase. The instruction appears even when the setup is correct. The message is part of the bug.

What is SUPABASE_PUBLISHABLE_KEY? The newer name for what Supabase used to call the anon key. Same value, same purpose, different label.

Is my data lost? No. The app cannot find its configuration, but your database is untouched. Once the variables are findable under the new names, everything comes back as it was.

Related field notes

If this incident has you thinking about how much of your backend you want to own, these go deeper: When to Use Lovable Cloud vs Your Own Supabase, The Real Cost of Owning Your Backend, and for where your backend code actually runs on the new stack, The TanStack Backend Map.

And if you are mid-migration from classic to TanStack: add "duplicate my Supabase secrets under the new names" to your pre-migration checklist. It is one minute of work that avoids exactly this afternoon.

Update note: I will update this post when the affected builders confirm the fix, and again if Lovable ships the platform-side mapping.