If you run Supabase on your own infrastructure, Supanator now talks to it. Same app, same UI, same security model. Just point it at your own stack instead of Supabase Cloud.
Add a self-hosted instance the same way you'd add a Cloud project. Paste your URL and keys, tweak a couple of advanced bits if your stack needs them, and the app runs a connection probe to figure out which services your stack exposes. You see the result before you finish setup.
What it works with
Four flavors of self-hosted Supabase are supported out of the box:
- The official self-hosted Docker setup
- Kubernetes deployments
- The Supabase CLI running on your laptop
- Custom Postgres databases with your own service mix
That covers the ways I've actually seen people run Supabase outside of Cloud. If you have a stack I'm missing, write in.
A compatibility chart, not a guessing game
Self-hosted Supabase is not one product. It's a collection of services that can be missing, swapped, or routed strangely depending on how you put your stack together. Some setups expose Realtime. Some don't. Some have Storage. Some have a stripped-down auth setup. Some sit behind a reverse proxy that mangles headers.
So before you connect, the connect sheet shows you a compatibility chart. Each row is a feature you might use (tables, SQL, auth users, storage browser, edge functions, realtime, advanced monitoring). Each column is your stack type. You see exactly what will work, what won't, and why, before you commit.
After you connect, if the probe finds something missing, that nav row just goes away. No empty screens, no confusing errors.
Auth, certificates, and the weird-network stuff
The hard part of self-hosted isn't the SQL. It's getting the request to the right place with the right headers. Real-world stacks do strange things.
So the Advanced section in the connect sheet handles:
- Reverse proxies and custom service paths
- Self-signed certificates with per-host trust (the trust override never leaks to other hosts the app talks to)
- HTTP Basic Auth in front of the stack
- Custom auth header names (some setups want
X-API-Keyinstead ofapikey) - Extra static headers applied to every outbound request
Both API key formats work too: legacy JWT keys and the new sb_publishable_* / sb_secret_* format.
Where the limits are
Self-hosted Supabase doesn't have a platform management API, so the things that depended on it don't apply:
- No managed backups or point-in-time recovery (you run your own)
- No Cloud advisors or SSL enforcement (your infrastructure, your call)
- No custom domain configuration through the app (your DNS, your reverse proxy)
- No project branches (a Cloud-only feature)
What you get in trade is a few tools Cloud users don't have, since direct Postgres access lets us do them properly:
- Active Connections with terminate
- Query Performance via
pg_stat_statements - Table Health (bloat, vacuum, analyze status)
- Lock Monitor with deadlock detection
- DB Migration assistant
These admin tools are Pro features, alongside Logs which has always been Pro. They read enough about your database that gating them felt right.
Apple Watch
The Watch app supports self-hosted too. The same account list shows on your wrist. Database size, connection count, table count, and active queries are read directly from your stack via pg-meta. Tiles that don't apply on self-hosted (request counts that depend on Cloud-only analytics) are hidden, so you get a clean dashboard instead of a row of zeros.
How to try it
If you have a Pro subscription on iOS, you have self-hosted access already. Add a new account, pick Self-Hosted, and paste your details. The compatibility chart shows you what to expect before you confirm.
If you run into a stack the app doesn't handle well, email me at [email protected]. As always, it's one person reading the inbox.