Lovable Supabase connection broke: 7 causes and the fix

Which Supabase connection problem do you have?

Two places tell you. Inside Lovable, open the project's Supabase view and read any warning. On the live app, open Chrome's developer tools (F12), choose Network, type supabase.co in the filter, and reload. Every request to the database shows up there with its status. Find your row:

A request with no status at all, or one shown as failed rather than as a number, never reached a working Supabase project. A number means Supabase answered, and the answer tells you what it didn't like. That split alone rules out half the causes.

Lovable Cloud or your own Supabase project?

Before fixing a connection, check which one the app has. Lovable's Supabase page says its built-in backend is on by default, so most projects never need a separate Supabase account. Lovable runs that backend for you on Supabase's open-source foundation, and the Cloud docs describe it as separate from an external Supabase project you connect yourself.

• Built-in backend (Lovable Cloud).You manage the database, users, and storage from Lovable's own views, under the More menu. The project won't appear in your Supabase account, and that's expected. Lovable handles the settings the fixes below change in the Supabase dashboard, and causes 3 and 6 don't apply.
• Your own Supabase project. You connected it under Settings, then External Supabase, and Lovable shows it under More, then Supabase. Every cause below applies, and the fixes happen in the Supabase dashboard.

So if you created a Supabase account later, looked for your tables, and found nothing, the connection didn't break. The data is where it always was. Lovable's docs are clear that a project doesn't move between the two in one step, so if the app works, leave it.

Cause 1: the Supabase project was paused

Supabase's pausing guide says free projects that show low activity over a 7-day period are paused to save resources. The owner gets a warning email about a week before and a confirmation once it's paused. Both go to whoever created the Supabase account, which is often not the founder, so the first sign is customers saying the app is broken.

A paused project doesn't answer at all. Lovable's Supabase page says a paused project can't be connected and shows "Check project status in Supabase", and its edge function docs say functions are unavailable while a project is paused. On the live app, requests to supabase.co fail without a status code.

How to resume a paused Supabase project

1. Sign in to the Supabase dashboard with the account that owns the project, open the organization, and select the paused project.
2. Click Resume project and confirm.
3. Wait for it to come back, then reload the live app. If it works, you're done. If it now fails with a 401, read cause 2 before anything else.

The guide says a few database requests a day over the previous week are usually enough to avoid a pause, and that a paused project can be restored for up to a year. If the app has real users, the reliable fix is a paid plan rather than a script that pings the database. The slow Lovable app guide covers the Lovable Cloud equivalent: a built-in database can also be paused when credits run out.

Cause 2: a restored project lost its anon key

This is the cause almost nobody expects, and it's new. Supabase is replacing its old anon and service_role keys with publishable keys (starting sb_publishable_) and secret keys (starting sb_secret_). Its API key docs say the old keys are being deprecated by the end of 2026. Supabase's published timeline for the change adds the detail that matters here: projects restored from 1 November 2025 are not restored with the legacy keys, and it warns that paused projects that are restored risk being broken because of it.

Open the app's .envfile and look at the Supabase key. Supabase's docs say a long key beginning with eyJis a legacy key. If that's what your app holds, this cause is waiting for it. So the sequence goes: the project pauses, someone resumes it, the project comes back with only the new keys, and every request from the app is rejected with a 401. Resuming fixed one problem and revealed the next.

How to switch a Lovable app to the publishable key

1. In the Supabase dashboard, open Settings, then API Keys, and the Publishable and secret API keys tab. Supabase's migration guide says to click Create new API keys if they don't exist yet.
2. Copy the publishable key into the app wherever the old anon key was. In a Lovable app that's the .env file, usually VITE_SUPABASE_PUBLISHABLE_KEY or VITE_SUPABASE_ANON_KEY, and the same variable on your host if the app is deployed outside Lovable. The publishable key is safe in the browser, the same as the anon key was.
3. Check every edge function. The migration guide says the new values arrive as SUPABASE_PUBLISHABLE_KEYS and SUPABASE_SECRET_KEYS, JSON objects you read by name, replacing SUPABASE_ANON_KEY and SUPABASE_SERVICE_ROLE_KEY.
4. Publish or redeploy, because VITE_ values are built into the app at build time.

// Before: Deno.env.get("SUPABASE_SERVICE_ROLE_KEY")
const secretKey = JSON.parse(Deno.env.get("SUPABASE_SECRET_KEYS")!)["default"];

One trap on the way. The guide says the platform's JWT check on edge functions only understands the legacy keys, so a function called with the new keys needs verify_jwt = false and its own check in code. Turning the check off without adding one opens the function to anyone, which is the same rule the edge function guide gives for 401 errors.

Cause 3: Supabase connection issue inside Lovable

Sometimes the live app is fine and only Lovable has lost the project. Lovable's Supabase page says it shows a connection issue when it can't find the connected Supabase project, and gives two reasons: the project was deleted in Supabase, or the workspace's access to the Supabase organization changed or expired. The symptom is Lovable failing to deploy edge functions or read the database, while customers notice nothing.

The fix, from the same page, is to click Disconnect to clear the broken link, or Manage organizations to reconnect the organization and pick the project again. Two permission rules catch people. Only workspace owners and admins can add or reconnect a Supabase organization, so a teammate with edit access sees the button greyed out. And the organization is authorized through a Supabase sign-in, so if the person who first connected it has left, or no longer has rights in that Supabase organization, someone who does has to reconnect it.

If the project really was deleted, there's nothing to reconnect. That's a restore-from-backup job, and the first question is whether a backup exists at all.

Cause 4: Invalid API key or legacy keys disabled

A 401 from Supabase with "Invalid API key" means the key the app sent isn't a working key for the project at that address. "Legacy API keys are disabled" is the specific case of an old eyJ key on a project where someone has turned those keys off. Both have three common origins:

• Someone disabled the legacy keys.A developer followed Supabase's migration reminders and switched the old keys off before the app was updated. The migration guide says disabling them is reversible, so turning them back on in Settings, then API Keys, restores the app in a minute while you do cause 2's swap properly.
• Someone rotated the keys after a leak.That's the right move, and the app needs the new key. The steps for doing it in the right order are in what to do when a Lovable API key is exposed.
• The key is from another project.The URL points at one project and the key belongs to another, usually after a second project was created for production. That's cause 6.

A secret key in the browser gives a 401 too. Supabase's API key docs say it recognises browser requests and rejects a secret key sent from one. If an AI fix "solved" a permission error by putting the secret key in the front end and it then failed, that failure is protecting you: the secret key bypasses every access rule.

Cause 5: supabaseUrl is required on a new host

This one appears the day an app moves off Lovable's hosting to Vercel, Netlify, or anywhere else. The page is blank and the console says supabaseUrl is required. The Supabase client was created with an empty address, because the variables that held it were in Lovable's .env file and never reached the new host.

Add the Supabase URL, publishable key, and project ID to the host's environment settings with the same names the code uses, then redeploy. The step that catches people is the redeploy: VITE_ values are baked into the build, so saving them in the dashboard changes nothing until the next build. The full list of variable names for both kinds of Lovable app is in the step-by-step guide to moving a Lovable app to your own hosting.

Cause 6: the app points at the wrong Supabase project

The quietest failure. Every request returns 200, nothing errors, and the data is wrong: old rows, test rows, or none. The app is connected, just to a different project from the one you're looking at in the dashboard. It happens when a second project gets created for production, when a project is remixed, or when a developer points a local copy at their own test project and that value gets committed.

Compare the project reference in two places. In the app, it's the part of VITE_SUPABASE_URL before .supabase.co, and VITE_SUPABASE_PROJECT_IDif the app has it. In the dashboard, it's in the address bar of the project you think is live. On the Network tab, the request addresses show the reference the published app actually uses. If they differ, decide which project holds the real data, point the app there, and publish. Then make sure the sign-in settings and secrets exist on that project too, because each project has its own.

Cause 7: a Lovable or Supabase outage

If everything failed at the same minute and nobody changed anything, check the status pages before touching settings: status.lovable.dev for Lovable and status.supabase.com for Supabase. Outages do happen on the connection itself. On 4 February 2026, Lovable's status page recorded about half an hour in which some users couldn't connect Supabase through Lovable's connectors, fixed the same afternoon.

An outage on the Lovable side usually affects the editor, not the live app, because a published app talks to Supabase directly. If customers can use the app and only Lovable is failing, wait it out. If the live app is down too and Supabase's status page is green, it's one of the causes above, not an outage.

How to stop the Supabase connection breaking again

Most of these causes are ownership problems, not code problems: an email nobody reads, a key nobody tracks, an organization one former contractor could access. Ten minutes on this list removes most of them.

1. Know which backend you have. Built-in or your own Supabase project, written down where the next developer will find it.
2. Own the Supabase organization.The founder's account should be an owner, so pause warnings and billing emails reach someone who acts on them.
3. Give a workspace admin access to it. Lovable only lets owners and admins reconnect the organization.
4. Move to publishable keys now. If .env holds a key starting with eyJ, do cause 2's swap before the end of 2026 deadline, or before the next pause and restore.
5. Stop pausing. Any app with paying users belongs on a paid Supabase plan or a paid Lovable plan with credits.
6. Have a backup you've tested. A deleted project with no backup is the one cause on this page with no fix.
7. Bookmark both status pages. Check them first, every time.

The free vibe-coded app launch checklist covers backups and secret keys alongside data access, if you want the rest of the pre-launch list.

When to get help with a broken Supabase connection

If the symptom table pointed at one cause and the fix worked, you're done. Get help when the project was deleted, when nobody has access to the Supabase organization any more, when the key swap breaks sign-in or edge functions, or when you can't tell which of two projects holds the real data. Those are the moments a quick fix can lose data or expose it. On The Chat Company, an AI-generated demo I took over, I kept about 20% of the code and rewrote the rest before it could serve real businesses. Nine weeks later it was a SaaS used by 30+ businesses.

A connection that breaks once usually breaks again, because the cause is that nobody owns the backend. That's what my care plan is for: you keep building in Lovable, and I own the Supabase project, keys, hosting, and backups, watch for errors, and fix what breaks, from $400 a month. It usually starts with a Launch-Ready Review, a fixed-price check for $900–1,500 in three to five days. Or just send me the app's linkand what the Network tab shows, and I'll tell you which cause it is.