Skip to main content
Hostwares

Where to Find Your Supabase Anon Key (and Service Role Key)

Hostwares Team·Published ·Updated ·2 min read

Your Supabase project ships with two keys, and using the wrong one is the most common way apps leak their entire database. Here is where each lives and which to use.

The 30-second answer

  1. Open your project in the Supabase dashboard.
  2. Go to Project Settings (the gear icon) → API.
  3. Under Project API keys you'll see two values:
    • anon public — safe for the browser. This is the one your frontend uses.
    • service_role secret — full admin access, bypasses Row Level Security. Server-side only.

Running Supabase yourself instead

The URL and keys above belong to a project on Supabase's hosted plan. If you have hit its limits - paused projects, a custom domain that needs a plan upgrade, or a bill that grew with usage - the same app runs unchanged on a dedicated Supabase instance from $5/mo: your own Postgres, auth, storage and edge functions on a server only you use, with a URL and keys of your own. The cost calculator shows what your current usage would cost there, and the custom domain guide covers putting your own domain on it.

Which key goes where

Where Key Env var
Browser / frontend anon public NEXT_PUBLIC_SUPABASE_ANON_KEY, VITE_SUPABASE_ANON_KEY
Server / API routes / edge functions service_role SUPABASE_SERVICE_ROLE_KEY (never prefixed PUBLIC)

The anon key is designed to be public — it only grants what your Row Level Security policies allow. The service_role key is the opposite: it ignores RLS entirely. If it ever reaches the browser bundle, anyone can read and write every row in your database.

The rule that keeps you safe

Never give a browser-exposed variable name (NEXT_PUBLIC_*, VITE_*) the service_role value. If you're not sure whether a key is exposed, assume it is and treat the service_role key like a password.

Related


Building this app? Deploy it on Hostwares. Connect your repo and HW — our AI DevOps agent — handles the move: it detects your framework, provisions or wires your database, injects the env vars your app expects (DATABASE_URL, SUPABASE_URL, SUPABASE_ANON_KEY…), and sets up SSL. You review and go live.

Create an account → · See how migration works →