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 →