Skip to content
Glossary

Supabase anon key vs service role key

Two keys, one rule: one may be public, the other must never leave the server. Mixing them up is the most expensive mistake in a Supabase app.

Plutonapps Engineering2 min read

In short

In Supabase, the anon key (now called the publishable key) identifies your app and is safe to ship in the browser, because row-level security decides what it can reach. The service role key (now the secret key) bypasses row-level security entirely, so it belongs only on a server and must never appear in client code.

Also called: Publishable key, Secret key, service_role key

Why it matters when your prototype goes to production

The public key is only safe because row-level security stands behind it. If a table has no policies, or security is off, anyone who copies the key from your site's JavaScript can read that table. If the secret key ends up in the browser, there is nothing behind it at all: Supabase's documentation says it bypasses row-level security, and so must never leave your control.

Anon / publishable keyService role / secret key
Where it livesIn the browser or appOn a server only
Row-level securityAppliesBypassed
If it leaksExpected; policies protect youFull access to your data: rotate it now

The naming change

Supabase has introduced publishable keys (they start sb_publishable_) and secret keys to replace the old anon and service_role keys, which its documentation says are being deprecated by the end of 2026. The rule is the same under both names.

Common questions

Is it safe to expose the Supabase anon key?

Yes, if every exposed table has row-level security enabled with the right policies. Without them, the key opens the table to anyone.

What should I do if the service role key leaked?

Rotate it immediately in the Supabase dashboard, move every use of it to server code, and check your logs for access you do not recognise.

More on this: Production architecture & security · All glossary terms

Built something in Lovable you want people to rely on?

We are the engineers who take it the rest of the way — secured, tested, released and supported.