Supabase

Last reviewed Aug 26, 2026 · 838 words

"Self-host Supabase" sounds like one app; it is closer to a dozen. The official Docker Compose stack runs Postgres plus a fleet of services around it — API gateway, auth, REST layer, realtime, storage, functions runtime, the Studio dashboard — and the catalogue's 4 GB RAM minimum and "Hard" difficulty rating are both earned. The payoff for carrying that weight is real: you get the Firebase feature set (instant APIs, auth, realtime subscriptions, file storage, edge functions) on top of a plain PostgreSQL database you fully own, under an Apache-2.0 license, with 108,000 GitHub stars' worth of ecosystem behind it. The question is whether your project needs the whole fleet.

Count the containers before you commit

Cloning the repo and running docker compose up from the docker/ directory brings up, at minimum: Postgres itself, Kong as the API gateway (everything routes through it, conventionally on port 8000), GoTrue for authentication, PostgREST for the instant REST API, Realtime for websocket subscriptions, the Storage API with an image transformation sidecar, an edge functions runtime, a Postgres metadata service, an analytics/log service, and Studio, the web dashboard. That is a lot of moving parts to keep patched and healthy, which is why 4 GB of RAM is a floor, not a target — give it 8 GB if users will actually touch it. The official self-hosting docs are genuinely good (the catalogue lists excellent docs as a headline pro, and I agree), but good docs do not shrink the stack.

Rotate every secret before first boot, not after

The compose setup ships with an .env.example full of demo credentials: a published JWT secret, matching anon and service_role API keys, a default dashboard login, and a default Postgres password. Because the example JWT secret is public, API keys derived from it are forgeable — an instance left on demo values is effectively open to anyone who finds it. Before the first docker compose up: generate a fresh JWT secret, mint new anon and service keys from it (the docs include a generator), and set your own database and dashboard passwords. Doing this after boot is worse than before, because issued tokens and stored auth data assume the old secret. Ten minutes of ceremony, non-negotiable.

Studio at home is not Studio in the cloud

The self-hosted dashboard gives you the table editor, SQL editor, and API docs, and that covers most daily work. What it does not give you is the hosted platform experience around it: one instance is one project, there is no organization or project-switching layer, no managed backups, and several dashboard sections assume platform services that simply are not present in the compose stack. Budget for doing those jobs yourself — pg_dump on a timer shipped off the box for backups, your own SMTP server or provider wired into GoTrue so signup and password-reset emails actually send, and your own TLS termination in front of Kong. None of this is hard for someone comfortable running the dev platforms tier of self-hosting; all of it is invisible on the hosted plan, which is exactly why the hosted plan exists.

The Postgres core is the escape hatch

The strongest argument for Supabase over its Firebase ancestor is that underneath everything sits a standard PostgreSQL database. Your schema is SQL, your row-level-security policies are SQL, and if you ever abandon the platform, pg_dump walks out the door with everything — no proprietary data model to escape. It also means the whole Postgres ecosystem applies: extensions, standard tooling, any ORM. If you are already convinced the database should be the center of your architecture, Postgres for everything makes the broader case; Supabase is that philosophy with batteries included.

Know when the answer is PocketBase

If your project is a side project, an internal tool, or an MVP for one team, weigh PocketBase before committing: a single Go binary, SQLite storage, auth and realtime and file storage built in, running happily in 128 MB where Supabase wants 4 GB. You give up Postgres, the SQL ecosystem, and horizontal headroom; you gain an operational footprint about 30 times smaller. I keep the full comparison in PocketBase vs Supabase, but the short version: self-hosted Supabase is justified when you need Postgres specifically, expect real scale, or are staging an eventual move to (or from) Supabase's cloud, where the same APIs and client libraries carry over.

What I'd do

Prototype against Supabase's hosted free tier first — same client code, zero containers — and self-host only once the project proves it deserves infrastructure. When that day comes: a dedicated VM with 8 GB RAM, the official compose stack, every secret rotated before first boot, Caddy in front of Kong for TLS, nightly pg_dump to another machine, and a calendar reminder to update images monthly. For anything smaller than that, run PocketBase and bank the difference in operational attention.