Self-hosted Supabase is the most requested and most underestimated deployment in the self-hosting world. People hear "open-source Firebase alternative" and picture a container. What Supabase actually is: eight cooperating services - Postgres with custom extensions, GoTrue for auth, PostgREST, Realtime, Storage, postgres-meta, Studio, and a Kong gateway in front - plus three optional ones. Most guides hide that; this one leads with it.
What you get in exchange for the complexity: your data on your infrastructure, no project-pausing (Supabase's free cloud tier pauses projects after a week of inactivity), and a flat infrastructure bill instead of per-project pricing. Disclosure as always: Miget is our platform, the template deploys there as a Compose Stack, and the base compose file runs anywhere Docker Compose does.
One honest label before we start: this is the largest template in the deployable.sh catalogue and it is marked experimental. Validate it on a dev project before you move anything real onto it.
What actually runs
| Service | Role | Public |
|---|---|---|
kong | API gateway - the only public entry point | yes |
studio | the Supabase dashboard (behind Kong basic auth) | via Kong |
db | Postgres - Supabase's own image with extensions and roles | no |
auth (GoTrue) | signups, logins, JWT issuance | via Kong |
rest (PostgREST) | the auto-generated REST API | via Kong |
realtime | websockets, DB change streams | via Kong |
storage + meta | file storage and schema introspection | via Kong |
Optional, enabled via compose profiles: pooler (Supavisor connection pooling), functions (edge runtime), imgproxy (image transforms).
Two design decisions worth understanding:
- Only Kong is public. Every API and the Studio dashboard route through it; Studio additionally sits behind Kong's basic auth (
DASHBOARD_USERNAME/DASHBOARD_PASSWORD). Your attack surface is one gateway, not eight services. - The database is deliberately NOT a managed Postgres. Supabase needs its own Postgres image - custom extensions, roles, and init SQL - so unlike most templates in the catalogue, this one runs the supabase-postgres container with its own volume. That means database operations (backups, upgrades) are on you; more below.
Deploy it in three steps
1. Create a Compose Stack in app.miget.com pointing at https://github.com/deployable-sh/stacks, path supabase.
2. Generate the secrets - all of them, properly. This is where self-hosted Supabase deployments go wrong. You need: POSTGRES_PASSWORD, JWT_SECRET (32+ characters), ANON_KEY and SERVICE_ROLE_KEY (JWTs signed with that secret - use Supabase's key generator, do not paste the demo keys from tutorials), DASHBOARD_USERNAME/DASHBOARD_PASSWORD, SECRET_KEY_BASE, and VAULT_ENC_KEY.
The trap: ANON_KEY and SERVICE_ROLE_KEY are derived from JWT_SECRET. Change the secret later and every issued key and session dies with it - generate once, store safely, treat like the n8n encryption key.
3. Set the URL variables and deploy. SITE_URL, API_EXTERNAL_URL, and SUPABASE_PUBLIC_URL point at the Kong app's public HTTPS domain (on Miget the overlay wires most of these to the assigned domain automatically). Then open the domain, log into Studio through the basic-auth prompt, and you have the familiar dashboard - on your own stack.
Local first? Same repo: cd stacks/supabase && cp .env.upstream-example .env, fill the secrets, docker compose up -d --build.
What it actually costs
Honest sizing, from the template's own numbers: the core stack totals about 6.5 GiB RAM - it fits Miget's 8 GiB plan at $49/month (20 GB disk included in sizing). Enable Supavisor, edge functions, and imgproxy and you are at ~9 GiB: size for the 16 GiB plan ($97/month) if you want everything on.
Compare that against what it replaces before deciding: Supabase Cloud's Pro tier starts at $25/month per project and scales with usage. Self-hosting wins when you run multiple projects, need data residency, or hit cloud limits - not when you have one small app and $49 > $25. We put the same honesty in our free PostgreSQL comparison: the right answer depends on which side of that line you are on.
Budget mode: the core stack for $13/month
There is a popular genre of "self-host Supabase for $3" posts, and the trick is always the same: run only the services your app actually uses - the database, Auth, and the REST API - and skip the rest. It is a legitimate trick; the $3 version just leaves you hand-rolling TLS and babysitting a VPS.
We packaged the same cut properly: the supabase-lite template runs Postgres, GoTrue, and PostgREST behind Kong - four services instead of eleven, ~600 MiB at idle, sized for the $13/month plan (2 GiB) with TLS and deploys handled. The Studio dashboard rides an optional profile you can toggle on when you are working on the schema. supabase-js works unchanged for database, auth, and REST calls, and the database volume carries over to the full template if you grow into Realtime or Storage later.
If your app does not touch Realtime, Storage, or edge functions, start there - it is the difference between $49 and $13 a month.
Or do you just need Postgres?
A chunk of "I want to self-host Supabase" is really "I want Postgres with a nice UI". If you are not using Auth, Realtime, or Storage, skip the eight services: a managed PostgreSQL instance (free tier available, HA clusters when it matters) plus any SQL client gets you there with none of the operational surface.
Production notes
- Experimental means experimental. Run a dev project on it first. The template is adapted from Supabase's official self-hosting compose, and upstream moves fast.
- Track upstream deliberately. The template vendors pinned upstream files and ships an
update-upstream.shscript - re-vendor, diff, and fold changes in on your schedule instead of discovering breaking changes in production. - Backups are yours now. The database is a container with a volume, not a managed service - schedule
pg_dump(or wire an external replica for the paranoid tier) before you put real data in. - Never ship the tutorial keys. The default
JWT_SECRETin every quickstart on the internet is the same string; anyone can mint a service-role key for a deployment that kept it. Generate your own everything. - The service-role key bypasses row-level security. It belongs in server-side code only - never in a browser bundle, same rule as on Supabase Cloud.
Frequently Asked Questions
How much RAM does self-hosted Supabase need?
About 6.5 GiB for the core stack (gateway, Studio, Postgres, Auth, REST, Realtime, Storage, meta); ~9 GiB with the optional pooler, edge functions, and image proxy. Plan for 8-16 GiB. Anyone quoting you 2 GiB is describing a demo, not a deployment.
Can I point self-hosted Supabase at a managed Postgres?
Not in this setup - Supabase requires its own Postgres image with custom extensions and roles, which is why the template deliberately runs the supabase-postgres container instead of provisioning a managed database.
Is self-hosted Supabase cheaper than Supabase Cloud?
For one small project, usually not ($49/month infrastructure vs $25/month Pro). It flips when you run several projects on one stack, need data residency, or would otherwise pay for cloud add-ons - and the free-tier project pausing goes away entirely.
How do I update self-hosted Supabase safely?
Use the template's update-upstream.sh to re-vendor the pinned upstream files, diff against the current compose, apply deliberately, and redeploy - after a database backup. Never track latest across an eight-service stack.
Is it production-ready?
The stack itself powers Supabase Cloud, so the components are. The self-hosted composition is marked experimental in the catalogue - validate on a dev project, keep backups, and treat the first month as a shakedown cruise.
What to read next
- Best Free PostgreSQL Hosting in 2026 - where self-hosted Supabase fits among the alternatives
- How to Self-Host n8n on Miget - the same production treatment for workflow automation
- Docker Compose Stacks - how the one-step multi-service deployment works