What the official self-hosted Supabase stack really needs: 8–16 GB sizing, docker compose, Kong, Studio and honest limits vs the cloud.
Self-hosted Supabase means the whole backend — Postgres with realtime, GoTrue auth, storage, Kong gateway and Studio — running on your VPS from the official docker compose stack. It is the same software as the cloud tier; what changes is who patches it and who backs it up: you.
apt update && apt install -y git ufw git clone --depth 1 https://github.com/supabase/supabase.git cd supabase/docker cp .env.example .env # edit .env: POSTGRES_PASSWORD, JWT_SECRET, ANON_KEY, SERVICE_ROLE_KEY # (generate: openssl rand -base64 32 for each secret) docker compose pull && docker compose up -d docker compose ps # a dozen containers should turn running
Never ship the example JWT keys — every Supabase tutorial checks them and they are public. Point your DNS A record at the server, then put Kong (port 8000) and Studio (port 3000) behind Caddy certificates, same pattern as the Node.js guide.
Point the SDK at `https://api.example.com` (Kong) with the `ANON_KEY` for clients and `SERVICE_ROLE_KEY` server-side only. Migrations run with the supabase CLI against your remote project — same workflow as the cloud, just against your own domain.
Cloud gives you managed upgrades, point-in-time backups, branching, and edge functions without setup — you pay per project and per usage. Self-hosting gives you flat costs, your data on your disk and no vendor lock — and hands you upgrades, backups and monitoring. Comfortable with `docker compose` and a restic timer? Self-host. Otherwise start on the free cloud tier and migrate later.
Database branching and the cloud dashboard niceties are cloud-only. Edge functions ship with the stack but expect more manual wiring than the managed version. Realtime works, scaled by your own Redis — fine for products, not for million-connection fan-out on a €34 box.
Backend you own, on hardware you chose. Core VPS 8 NVMe (24 GB, €34/mo) →