Supabase legacy API keys are going away: will your app break, and how to switch

Short answer: yes, an app that still uses the legacy anon or service_role key will break when Supabase removes them. Supabase is deprecating both keys "by the end of 2026". Its timetable says that in late 2026 (exact date still "TBC") the legacy keys "will be deleted", and "You have to migrate to use the new API keys by this point or your app will break."

Get it fixed: a free check first confirms the problem on your live app, usually in 4 to 10 minutes.

Your live app’s link It’s my app — the AI agent may sign up once as “VibeFix Test”. Check my app free

Free. No account needed. It usually takes 4 to 10 minutes.

Want it fixed? Our AI agent fixes it in your code and tests your live app again. See pricing.

The fix is to use a publishable key (sb_publishable_...) wherever your app used anon and a secret key (sb_secret_...) wherever it used service_role. The old and new keys work side by side, so you can switch one place at a time. Deactivate the legacy keys only once nothing uses them.

Login, emails or payments broke in your live app? Our AI agent fixes it in your code, then tests your live app again.

Fixed in your code, then tested live. Check my app free

Does my app still use the legacy Supabase keys?

Check the key itself, your dashboard, and every place outside the app that talks to Supabase.

• The key itself: a legacy key is a long string that begins with eyJ. A new key is a short string that starts with sb_publishable_ or sb_secret_. Supabase says: "If a tool, tutorial, or AI assistant tells you to copy a long key that begins with eyJ, it was written for the legacy keys" (Supabase: API keys).
• Your dashboard: open Settings > API Keys. "If you see a Create new API keys button, your project is still on legacy keys only" (Supabase: migrating to the new API keys).
• Your app's settings: look for environment variables or secrets that hold an eyJ... value. Common names are SUPABASE_ANON_KEY and SUPABASE_SERVICE_ROLE_KEY, or a VITE_ variable in your front end.
• Places outside the app: Supabase lists servers, Edge Functions, workers and other backend code for the service_role key, and web pages, mobile and desktop apps, CLIs and scripts that ship to users for the anon key. Database Webhooks and pg_net calls usually send the service_role key too.

When will the legacy Supabase keys stop working?

There is no exact date yet. Supabase's own timetable gives "Late 2026, TBC", and its docs say "by the end of 2026".

Supabase's timetable (GitHub announcement):

• June 2025: new API keys introduced. New projects got both new and legacy keys.
• November 2025: monthly reminders to migrate started. "Projects restored from 1st November 2025 will no longer be restored with the legacy API keys." New projects no longer have anon and service_role available.
• Late 2026, TBC: "Legacy API keys will be deleted and removed from the Docs / Dashboard. You have to migrate to use the new API keys by this point or your app will break."

Until then, your legacy keys keep working. Creating the new keys does not turn the old ones off.

My Supabase project was paused, I restored it, and now my app is broken

This can be the key change arriving early. Supabase warns that "paused projects that are restored risk being broken as they won't have the legacy keys."

A project restored from 1 November 2025 comes back without its anon and service_role keys. A front end that still carries the old eyJ... key may then stop working. Create the new keys, put the publishable key in your front end and the secret key in your backend, then publish again. More on paused projects: Supabase free project paused.

How do I switch my app to the new Supabase keys?

Create the new keys, swap them in place by place, test your live app, and only then deactivate the old ones.

1. Create the new keys. In Settings > API Keys, create the publishable and secret keys. Supabase: "Creating the new keys is safe. It adds a publishable key and a secret key alongside your existing anon and service_role keys. Your legacy keys keep working."
2. Front end: swap anon for the publishable key. "Anywhere you use the anon key in public code, switch to the publishable key. This includes web pages, mobile and desktop apps, and any CLI or script that ships to users."
3. Publish your front end again. Front-end variables are built into your app when it is built, so changing the value alone does not change the live app. Lovable's docs, for example, say its VITE_ variables are "embedded into the client bundle at build time" (Lovable: secrets).
4. Backend: swap service_role for a secret key. Use it only in servers, Edge Functions, cron jobs and other code you control. Send it on the apikey header.
5. Test your live app as a signed-out visitor and as a signed-in user: sign-up, login, saving data, payments and anything that runs on a schedule.
6. Deactivate the legacy keys in Settings > API Keys once nothing uses them. "You can re-activate them if you find a client you missed, so this step is reversible."

What can break when I switch Supabase keys?

The new keys are not JWTs. These problems come from code that still treats the key as one, or from a secret key in the wrong place.

• "Invalid JWT" from an Edge Function: the new key was sent on the Authorization: Bearer header, which many Supabase clients do by default. "The platform's built-in verify_jwt check only understands the legacy JWT-based keys." Supabase's fix: set verify_jwt = false for those functions and authorize the key in your own code. Do not turn the check off without that code, or anyone could call the function.
• HTTP 401 in the browser: a secret key was used in front-end code. Secret keys "return HTTP 401 if used in a browser". Use the publishable key there.
• Database Webhooks or pg_net calls fail: they usually send the key on Authorization: Bearer. "The new secret keys aren't JWTs, so they're rejected there." Send the secret key on the apikey header instead.
• Live updates drop after a day: "Public Realtime connections are limited to 24 hours unless the connection is upgraded" with a signed-in user.

Is the Supabase publishable key safe in my front end?

Get it fixed: a free check first confirms the problem on your live app, usually in 4 to 10 minutes.

Your live app’s link It’s my app — the AI agent may sign up once as “VibeFix Test”. Check my app free

Free. No account needed. It usually takes 4 to 10 minutes.

Want it fixed? Our AI agent fixes it in your code and tests your live app again. See pricing.

Yes. Supabase calls the publishable key "Safe to expose online", but adds: "Anyone can read it, so it only reaches what Row Level Security allows."

So row level security must be on, with policies for each table your front end reads or writes. The secret key is the opposite: "Never put one in a browser, a shipped application, or source control." If a service_role or secret key was ever in your front end, treat it as leaked. Supabase has a page on how to rotate a leaked or compromised key (Supabase: API keys).

FAQ

Is there an exact date when Supabase removes the legacy keys?

Not yet. As of 5 November 2026, Supabase gives "Late 2026, TBC" in its timetable and "by the end of 2026" in its docs.

Will my app break the day I create the new keys?

No. Creating the new keys adds them next to the legacy keys, and the legacy keys keep working until you deactivate them or Supabase removes them.

Can I undo deactivating the legacy keys?

Yes. Supabase says you can re-activate them if you find a client you missed.

Does this affect apps built with an AI builder?

Yes, the same way. If the app's settings hold an anon or service_role key that begins with eyJ, it needs the switch.

Do I need new keys if my Supabase project is new?

New projects created since November 2025 don't get the legacy keys at all, so they already use the new ones. Code or a tutorial that asks for a key beginning with eyJ was written for the legacy keys.

Can VibeFix fix it for me?

Yes, if you ask. The free check confirms the problem first. Our AI agent can find the cause, fix it in your code and test your live app again. The price is on the pricing page.

Still broken?

If your live app stopped working after the key switch, or after you restored a paused project, start with a free check. Tell us what broke: our AI agent tries your live app like a real person and shows you the problem with a screenshot. The free check never changes your app. If you want it fixed, it reviews your code independently, because VibeFix isn't part of any app builder, fixes it in your code and tests your live app again. Today the fix is for apps built with Lovable, or any app whose code is on GitHub.

Fixed in your code, then tested live. Check my app free

Related: Supabase free project paused · Secret key or admin page visible · Users can see other users' data · Supabase "permission denied for table" (42501) · Supabase RLS policy generator

VibeFix is independent. Lovable, Bolt, Replit, Base44, v0, Supabase, Firebase, Stripe and Vercel are trademarks of their owners.