Self-Hosted Supabase vs Managed: Cost and Effort
Self-hosted Supabase is free software you run with Docker on your own server, and it makes sense when you need full control of where data lives or have compliance rules that rule out managed services. For most small teams it is not cheaper than Supabase Cloud once you count your time: you take over backups, upgrades, security and monitoring, and you lose managed point-in-time recovery, branching, the Management API and multiple projects per dashboard.
This article goes through what self-hosting actually involves as of November 2026, based on Supabase's self-hosting docs, and gives you a way to compare the two on cost. At the end we cover a third route, a managed host that speaks the same APIs.
#What you run when you self-host Supabase
Supabase's Docker setup starts a set of containers that together make up the stack:
- Postgres, the database itself
- Auth, the user and token server
- PostgREST, the REST API generated from your schema
- Realtime, for database changes, broadcast and presence
- Storage plus imgproxy for image transformations
- Edge Runtime for Deno functions
- Supavisor, the connection pooler
- postgres-meta and Studio, the dashboard
- An API gateway in front (Envoy by default, Kong optional)
- Optional Logflare and Vector for logs and analytics, off by default to save memory
#Server requirements
| Minimum | Recommended | |
|---|---|---|
| RAM | 4 GB | 8 GB or more |
| CPU | 2 cores | 4 cores or more |
| Disk | 40 GB SSD | 80 GB SSD or more |
You can drop services you don't use (Realtime, Storage, imgproxy, Edge Runtime) from the compose file to lower these.
#The install
The docs offer a Linux quick-start script, or a manual route: clone the repository, copy the docker/ folder into a project folder, create .env from the example file, pull the images and start them. The real work is in .env:
- Generate your own keys and secrets. The docs are explicit that you should never start a self-hosted instance with the default values. Scripts generate the API keys and the JWT signing keys.
- Set the public URLs (
SUPABASE_PUBLIC_URL,API_EXTERNAL_URL,SITE_URL). - Set a dashboard password.
- Configure SMTP so Auth can send confirmation and magic-link e-mails.
- Optionally point Storage at S3-compatible storage; by default files go to the local disk.
- Put a reverse proxy with HTTPS in front for production.
An experienced operator can have this running in an afternoon. Getting it production-ready (TLS, firewall, off-site backups, monitoring, alerting) takes longer.
#What you don't get when self-hosting
Supabase's docs list features of the managed platform that are not available self-hosted. As of November 2026 they include:
- Branching (preview databases per pull request)
- Managed backups and point-in-time recovery
- The Management API
- Multiple organizations or projects in Studio: one stack, one project
- Advanced metrics beyond logs, analytics, vector buckets and ETL
Self-hosted Supabase is also community-supported: help comes from GitHub, Discord and Reddit, not a support desk, unless you have an enterprise agreement.
The single-project point matters for cost. If you have three apps, or want staging next to production, you run three stacks, each with its own memory footprint.
#The jobs you take over
When you self-host, Supabase's docs say you are responsible for server provisioning and maintenance, backups and disaster recovery, and monitoring and uptime. In concrete terms:
| Job | How often | What it involves |
|---|---|---|
| OS and Docker updates | Monthly, plus urgent security fixes | Patching, rebooting, checking that containers come back |
| Supabase upgrades | Stable snapshots roughly monthly | Running the update script (a three-way merge of config), testing, rolling back if needed. Mixing image versions is not guaranteed to work. |
| Postgres major upgrades | Every year or two | Dump/restore or pg_upgrade, downtime planning |
| Backups | Continuous | pg_dump on a schedule, or WAL archiving for point-in-time recovery, shipped off the server, and restore drills |
| Storage files | Continuous | Backing up the volume or bucket separately from the database |
| Monitoring | Always | Disk space, memory, container health, certificate expiry, alerting to your phone |
| Security | Always | Firewall, rotated secrets, Postgres not exposed to the internet, Studio behind authentication |
| Incidents | When they happen | You are the on-call |
None of this is hard on its own. It adds up, and it never stops.
#A way to compare the cost
Prices for servers vary too much by provider and region to quote one number, so use this formula with your own figures:
Self-hosted monthly cost = server(s) + backup storage + (hours per month × your hourly rate)
Managed monthly cost = plan + compute + usage + add-ons
For the managed side, Supabase Cloud as of November 2026 (from supabase.com/pricing): Pro from $25 a month with $10 of compute credits (one Micro instance, 1 GB RAM), Small compute at $15 (2 GB), Medium at $60 (4 GB), Large at $110 (8 GB). Point-in-time recovery is $100 a month per 7 days of retention and needs at least Small compute. Branching is $0.01344 per branch-hour.
Some honest observations:
- The minimum self-hosted box (4 GB RAM) is closer to Supabase's Medium compute than to Micro. A small VPS may be cheaper than $60, but the comparison is not $5 versus $25.
- Two hours a month of maintenance at a modest rate already exceeds the price of Supabase Pro. Many teams spend more than that in the first months.
- PITR changes the math. If you need point-in-time recovery, the managed add-on is $100+ a month. Self-hosting it means setting up WAL archiving yourself (for example with pgBackRest or WAL-G) and testing restores.
- Self-hosting wins at scale on raw compute. If you need 64 GB of RAM and have someone who already runs Postgres in production, your own hardware is much cheaper per GB than managed compute.
#When self-hosting is the right call
- You must keep data on infrastructure you control, for legal or contractual reasons.
- You need an isolated environment, such as an air-gapped network or an on-premise install for a customer.
- You already run Postgres in production and have on-call coverage.
- You need large, predictable compute and the managed price for it is far above your hardware cost.
- You want to learn how the stack works. Running it yourself is a great way to understand it.
#When managed is the right call
- You are a small team and want to spend time on the product.
- You need backups you don't have to think about, and point-in-time recovery.
- You run several projects or want preview branches.
- Nobody on the team wants to be paged at 3 a.m. for a full disk.
#A third option: a managed host with the same APIs
Some teams self-host mainly to keep data in Europe or to avoid Supabase's per-project compute pricing. A compatible managed platform can cover those reasons without the operations work.
StitchDB is a hosted backend that speaks the same APIs as the open-source Supabase stack: the PostgREST-style REST API, Auth, Storage, Realtime and Deno Edge Functions, with the same paths, JWT roles and error formats. Apps built on supabase-js or supabase_flutter work after changing the project URL and keys (compatibility). Compared with self-hosting:
- Backups are managed on paid plans. Every paid project can be restored to any moment in its window: 7 days on Pro, 14 on Scale, 30 on Enterprise (backups). Free projects have no backups, so export your own copies.
- Multiple projects and preview branches are part of the plans: Pro ($15.99) includes 3 branches, Scale ($49) includes 5 (branching).
- Hosting is in the EU only: Falkenstein and Nuremberg in Germany, Helsinki in Finland.
- Dedicated servers are available on Scale and Enterprise if you want a box that runs only your projects (compute). Accounts the StitchDB team has enabled can also attach servers they own: StitchDB installs its stack on them, runs only that account's projects there and stores backups off the server.
- Local development without Docker:
stitchdb startruns Postgres, Auth, REST, Realtime, Storage and Edge Functions on your machine as plain processes (local development).
The trade-offs are real. There is no self-hosted edition of StitchDB, so it does not solve an air-gapped or on-premise requirement. It has no regions outside Europe, and it is a younger platform than Supabase. If any of those is a hard requirement, self-hosted Supabase or Supabase Cloud is the better fit.
Moving an existing self-hosted instance is the same as moving any Postgres: the Import from Postgres wizard copies schemas, data, auth users with their password hashes, files and cron jobs, with a live copy when the source has logical replication turned on. For more options, see Supabase alternatives and dedicated vs shared Postgres.
#FAQ
#Is self-hosted Supabase free?
The software is free and open source. You pay for the servers, backup storage and the time to run them.
#Can I run multiple projects on one self-hosted Supabase?
Not from one Studio. Supabase's docs say self-hosted Studio doesn't support multiple organizations or projects, so each project is its own stack.
#Does self-hosted Supabase include point-in-time recovery?
No. Managed backups and PITR are listed as unavailable when self-hosting. You can build PITR yourself with WAL archiving tools and regular restore tests.
#What are the minimum requirements to self-host Supabase?
4 GB of RAM, 2 CPU cores and a 40 GB SSD, with 8 GB, 4 cores and 80 GB recommended, as of November 2026.
#Can I move from self-hosted Supabase to a managed host later?
Yes. Any Postgres 12 or newer can be imported into StitchDB, and apps keep working after the URL and key change.
See what managed would cost you on the StitchDB pricing page.