How to rotate your Supabase API key

Updated October 2026

A new Supabase key runs side by side with the old one, so nothing breaks the moment you create it. The risk with Supabase isn't the swap itself, it's forgetting to go back and delete the old key once you're done.

Here's the manual process, from Supabase's own docs.

The manual steps

1. Go to Settings > API Keys in your Supabase dashboard.
2. Create a new publishable or secret key.
3. Replace the old key everywhere your app uses it, environment variables, CI secrets, any function that calls Supabase.
4. Confirm every part of your app is now using the new key.
5. Delete the old key in the dashboard. Supabase's docs are clear that "this action cannot be undone."

Supabase's own docs explain why nothing breaks right away, checked October 24, 2026: "Creating a publishable or secret key adds it alongside your existing anon and service_role keys without affecting them, so your legacy keys keep working."

The legacy anon and service_role keys are different

If your project still uses the older anon and service_role JWT keys, don't delete them, disable them instead. Supabase's own docs describe disabling as reversible, checked October 24, 2026, which matters because there's no documented endpoint that rotates the underlying JWT secret safely. If you find a client still depending on the legacy key after disabling it, you can turn it back on while you fix that client.

What breaks if you miss a place

Nothing breaks immediately, which is exactly the trap. Because the old key keeps working until you manually remove it, a forgotten old key just sits there, live, for as long as nobody deletes it. The real risk with Supabase rotation is an old key that should have been killed weeks ago and never was.

How to check the old key is actually dead

After deleting it, send a request with the old key using only the apikey header, not Authorization: Bearer, which Supabase's own migration guide warns gets treated differently, checked October 24, 2026. A dead key should fail the request. The hosted platform's exact response code for this probe isn't written down in Supabase's docs, so confirm it once on your own project rather than assuming.

Or let Key Robot do it

Key Robot does this for you today. It creates the new secret key, puts it in your app on Netlify or Vercel, checks that your app still works with it, and only then deletes the old one, closing the exact gap above where a forgotten old key stays live for no reason. It runs from your own GitHub Actions, with the key locked in your browser and never stored on Key Robot's own server. In our test on October 25, 2026, one change took 19 seconds.

We hold every new integration to the same bar as the live ones. Our own test kit runs 8 checks on every service we support, and it already caught a bug in our own code where Kill it now kept a leaked secret working as a backup value. We fixed it before launch.

A quick habit that catches the forgotten-delete problem

Put a reminder on your own calendar for a week after you create any replacement key, just to go check whether the old one is still sitting in the dashboard. It's a small habit, and it directly targets the one failure mode Supabase's own design makes easy, a swap that technically finished but never got cleaned up.

See how to rotate your Neon database password for a service Key Robot already handles, or how to rotate your Cloudflare API token for the next one coming after this.