service_role key

service_role key is the Supabase API key that bypasses Row Level Security and can read or write every row in every table, regardless of policy.

It is a signed JWT with the service_role claim. Because it ignores RLS, it must stay server-side: Edge Functions, backend jobs, CLI scripts. Never embed it in client-side code or expose it in the browser — anyone who reads it gets full read/write access to your database. Contrast it with the anon key, which is safe to ship to clients precisely because RLS still applies to it.

A migration needs this level of access. Copying auth.users rows, resyncing sequences, and writing tables that carry restrictive policies all require reading and writing rows the anon key would be blocked from. SupaMigrate uses the service_role key of both the source and destination projects for exactly these steps, holds it only in browser memory during the run, and never stores it server-side.

You can decode the key to confirm its role before using it:

# The payload of any Supabase JWT is base64url in the middle segment
echo "$SERVICE_ROLE_KEY" | cut -d. -f2 | base64 -d 2>/dev/null
# {"iss":"supabase","role":"service_role","iat":...,"exp":...}

If the decoded role is anon, you have the wrong key and writes to policy-protected tables will fail. Find both keys under Project Settings → API in the Supabase dashboard.