This article is part of our AI-Built Site Rescue hub. Want help applying it? Talk to eSEOspace.
Your app could stop working if it still depends on Supabase's anon and service_role keys when they are removed. Supabase says it is deprecating those keys "by the end of 2026," but we found no exact shutdown day.
Many apps built with AI tools were generated with these older keys. Nothing is wrong with using AI to build an app, but this is the kind of change that goes unnoticed without someone maintaining it. This guide is part of our AI-Built Site Rescue hub, and was checked against Supabase's documentation on 9 November 2026.
Key Takeaways
- Supabase says it is deprecating the
anonandservice_rolekeys by the end of 2026. - Its GitHub timetable lists removal as late 2026, with the date still to be confirmed.
- Creating new keys does not turn off the old ones, so you can migrate in stages.
- Deactivate legacy keys only after confirming nothing depends on them, including older mobile app versions.
- Replacing keys does not fix weak database rules, so review Row Level Security as well.
What is changing
Supabase has two sets of API keys. The older set is called anon and service_role, and the newer set is called publishable and secret.
The Supabase API keys guide says: "Supabase is deprecating the anon and service_role keys by the end of 2026." It tells developers to use publishable (sb_publishable_xxx) and secret (sb_secret_xxx) keys instead.
| Old key | New key | Where it belongs |
|---|---|---|
anon | Publishable key | Browser, mobile app, public scripts |
service_role | Secret key | Servers and backend code you control |
Will my app stop working?
It may, if you do nothing and the keys are removed. Supabase's original announcement on GitHub lists late 2026 for this step: "Legacy API keys will be deleted and removed from the Docs / Dashboard."
That row is marked as still to be confirmed. The same post warns that you have to migrate by this point "or your app will break."
Here is what we could and could not confirm on 9 November 2026.
| Question | What we found |
|---|---|
| Is the deprecation announced? | Yes, in Supabase's docs |
| Is there a stated deadline? | "By the end of 2026" in the docs, late 2026 in the GitHub post |
| Is there an exact shutdown day? | We did not find one |
| Could the date move? | It has moved before; a December 2024 update in the post delayed the rollout |
Plan as if the end of 2026 is real. Then check the Supabase docs again before you make decisions, because the wording can change.
Some projects are already affected
The GitHub post says projects restored from 1 November 2025 "will no longer be restored with the legacy API keys." It warns that restored projects risk being broken without them.
The same post says new projects no longer have the legacy keys available. So if you paused an older project and brought it back, check it first.
How to tell if your app uses legacy keys
You can usually find out in a few minutes.
- Open your Supabase project and go to Settings, then API Keys.
- Look for the option "Create new API keys." Supabase says that means your project has only legacy keys.
- Search your code and hosting settings for
anonandservice_role. - Look at the key values. Legacy keys are long JWTs, a kind of signed token, while the new ones are short strings starting with
sb_publishable_orsb_secret_.
If an AI tool or builder manages your Supabase connection, check that tool's settings too. We did not review how each builder handles this change, so ask its support team.
The safe order to migrate
Supabase's migration guide gives the order. It says to "swap clients one at a time and deactivate the legacy keys only after nothing depends on them."
- Create the new keys. Do this in Settings, then API Keys. Creating them doesn't disable your legacy keys.
- Swap the publishable key in client code. Replace
anonin browsers, mobile apps, desktop apps and public scripts. - Swap the secret key in backend code. Replace
service_roleon the servers you control. - Update Edge Functions. These are small server functions that run on Supabase.
- Check that nothing still uses the legacy keys.
- Deactivate the legacy keys. Supabase says this step is reversible if you find a client you missed.
The two systems can run together during this work. Supabase's API keys guide says "Both key systems work at the same time," and legacy keys "stay valid until you disable them."
Three places people get caught
Edge Functions. Supabase says the built-in verify_jwt check "only understands the legacy JWT-based keys." Follow the guide's steps for this, or requests can fail after the swap.
Mobile apps. Supabase lists "Mobile or desktop app versions already in users' hands" in its checklist before turning legacy keys off. Old app versions keep calling with the old key until people update.
Database webhooks. Supabase says to send the secret key on the apikey header, not Authorization: Bearer. A find-and-replace on the key value alone will miss this.
What to do if a key has leaked
Migration is routine work, and a leak is an emergency. If a service_role key or a secret key has been exposed, handle that first.
Supabase publishes a separate guide to rotating a leaked key. Our checklist for what to do in the first hour covers the wider steps.
Do not stop at the key swap
New keys do not change what your database allows. The Supabase guide says a publishable key "only reaches what Row Level Security allows."
So if your database rules are missing or weak, the new key inherits that problem. Read Row-Level Security in plain English and then check your tables.
Supabase also notes that a secret key "bypasses Row Level Security," so it "must never leave your control." Keep it out of browser code, public repositories and shipped apps.
Next step
If you would rather not manage this change yourself, talk to us about handling it. A review reduces risk, but it cannot promise that nothing will break.
Frequently asked questions
When exactly will Supabase remove legacy keys?
We did not find an exact day. The docs say "by the end of 2026," and the GitHub timetable says late 2026, to be confirmed. Check both pages before you plan around a specific date.
Is the anon key a security problem?
The docs describe anon as the legacy version of the publishable key, which is meant for public use. What protects your data is your Row Level Security policies. The service_role key is different and must stay private.
Can I run old and new keys at the same time?
Yes. Supabase says both key systems work at the same time. That lets you move one client at a time before you turn the old keys off.
What happens if I turn off legacy keys too early?
Anything still using them will fail. Supabase says deactivation can be reversed if you find a client you missed. That is why the checking step comes before deactivation.
Do I need to change my JWT signing keys too?
Supabase calls JWT signing keys "a separate, independent migration." It is worth doing, but it is not the same job. Follow its guide for that change on its own.
My app was built with an AI tool. Does this still apply?
Yes, if the app talks to Supabase with the older keys. The tool that wrote the code does not change how Supabase handles them. Check your project settings and your code.
