I removed the key from my code. Am I safe now?

No. It’s still in your git history and in any build that was deployed, and anyone who copied it can keep using it until you retire it in Supabase. Rotate it.

Is the anon or publishable key a problem too?

No. Those are meant for the browser. They’re only safe if row-level security protects your tables, so check your policies while you’re there.

Can you rotate the key for me?

The rotation happens in your Supabase dashboard, so it stays with you. We fix the code that leaked the key and move those calls to the server, as a pull request you review and deploy, with the rotation steps for your project in the right order.

Can you fix it for me?

If one bug is the whole problem, the App Fix Ticket covers it: a written diagnosis first, then the fix. If the app has more going on, the Launch Check is a written check of the whole app. Each issue found is rated critical, high, medium or low, with where it is and how it was confirmed. No issues worth fixing, no charge. If the Launch Check finds nothing rated medium or higher, Simon refunds the full $450. You keep the report either way.

Supabase service_role Key Exposed? What to Do

Supabase key leakMy Supabase service_role key is exposed

Someone, or a scanner, found your service_role key in the JavaScript your site loads, in a public repo or in a screenshot. That key skips row-level security, so whoever has it can read, change or delete every row. Here’s the order Supabase gives for replacing it, or hand the fix over at a fixed price.

Short answer

Treat the key as compromised. Fix how it leaked first, or the new key leaks the same way. Then create a new secret key, replace the old one everywhere, confirm nothing still uses it, and retire the old key. If it was a legacy service_role key, also revoke the legacy JWT secret. If someone is actively using the leaked key, retire it right away and do the leak fix afterwards. Retiring legacy keys also switches off the anon key, so the site breaks until your apps move to a publishable key. Then check your Supabase logs and tables for changes you didn’t make.

The steps, in Supabase’s order

01
Fix how it leaked
“Fix the root cause of the leak before you rotate anything.” Supabase, Rotate a leaked or compromised API key
Usually the key went into front-end code, often as a VITE_ or NEXT_PUBLIC_ variable, which builds it into the JavaScript every visitor downloads. Move the calls that need it into a server function or an Edge Function, so the browser only has the publishable or anon key. Deleting it in a later commit isn’t enough: it stays in your git history and in builds already deployed.
02
Create a new key and switch to it
Create a new secret key under Settings, API Keys, and put it everywhere the old key was used: server code, Edge Functions, webhooks and scheduled jobs. If the leaked key was a legacy service_role key, also move your browser and mobile apps from the legacy anon key to a publishable key, because retiring the leaked key turns off both legacy keys. Then confirm every part of the app uses the new key.
03
Retire the old key
“Deleting a secret key can't be undone.” Supabase, Rotate a leaked or compromised API key
Unless someone is actively using the key, wait until everything runs on the new one first. Then delete a leaked secret key, or deactivate the legacy keys if it was service_role. If you find a client you missed afterwards, move it to a new key: turning the legacy keys back on brings the leaked one back too. For a legacy service_role key, also revoke the legacy JWT secret, because anything that still trusts that secret can accept the leaked key.

Checked against the vendor’s docs on October 31, 2026: Supabase docs: Rotate a leaked or compromised API key; Supabase docs: API keys; Supabase docs: JWT signing keys.

Rather hand it over?

Fixed scope, fixed price, paid upfront. The work happens in writing; no call needed.

Supabase key leakMy Supabase service_role key is exposed

The steps, in Supabase’s order

Fix how it leaked

Create a new key and switch to it

Retire the old key

Rather hand it over?

More on this error

Describe it and get a written quote