SecureStartKit
SecurityFeaturesPricingDocsBlogChangelog
Sign inBuy Now
Home/Glossary/Service role key
Data Layer

Service role key

Also known as: SUPABASE_SERVICE_ROLE_KEY, service_role, admin key

Definition

The service role key is the Supabase API key that bypasses Row Level Security and grants full database access. It must never enter the browser bundle. In a Next.js app, the service role key is used only in Server Actions and Route Handlers via createAdminClient, with the import gated by Next.js's server-only enforcement.

What is the service role key?

Supabase issues two keys per project: an anon key (safe for the browser, respects RLS) and a service_role key (server-only, bypasses RLS). The service_role key is the equivalent of a Postgres superuser for the project's PostgREST API. Anyone who has the key can read or modify any row in any table.

How do you prevent service_role from leaking to the browser?

Use import 'server-only' at the top of every file that touches the key. The Next.js compiler refuses to bundle any module marked server-only into client output, so even a transitive import from a Client Component triggers a build error. Combined with naming the env var SUPABASE_SERVICE_ROLE_KEY (no NEXT_PUBLIC_ prefix), the key has two structural barriers against leaking.

When should you use service_role vs anon?

Service_role for admin operations (webhook handlers, scheduled jobs, system tasks) and for backend-only data access where the Server Action does its own authorization. Anon for client-side reads where RLS provides the authorization. Never instantiate a service_role client in any code path that runs in the browser.

Learn more

  • Backend-only Data Access
  • Exposed API Keys: How AI Tools Leak Secrets
  • Exposed service_role Key: the fix

Related terms

  • Anon keyThe anon key is the Supabase public API key that respects Row Level Security. It is safe to include in the browser bundle because RLS gates every query against the user's JWT claims. The anon key alone cannot read or modify rows unless an RLS policy explicitly allows it.
  • Backend-only data accessBackend-only data access is an architectural pattern where the database is never queried directly from the browser. All queries run through Server Actions or Route Handlers using the service_role key, after server-side authentication and Zod validation. The browser only receives data the server explicitly returns.
  • Row Level SecurityRow Level Security is a Postgres feature that filters which rows of a table each user can see or modify. In Supabase apps, RLS policies are written in SQL and evaluated on every query against the authenticated user's JWT claims, making the database itself the authorization boundary.
← Back to full glossary