# How to self-host Supabase, and what you take on

> Yes, you can self-host Supabase with its official Docker Compose setup. Installing takes an afternoon; TLS, email, backups, upgrades and security are yours.

Source: https://supahost.app/guides/self-host-supabase · Updated 2026-11-11

Yes, you can self-host Supabase. Supabase is open source, and its official [self-hosting guide](https://supabase.com/docs/guides/self-hosting) uses Docker Compose to run the whole stack on a server you control. Getting it running takes an afternoon; keeping it secure, backed up and up to date is the ongoing work, and that's what this guide is mostly about.

Details below come from the Supabase self-hosting docs as of November 2026. The setup changes between releases, so follow the [Docker guide](https://supabase.com/docs/guides/self-hosting/docker) itself when you install.

## What you get when you self-host

The Docker Compose setup runs the same open-source services that power Supabase:

- **Postgres**, with Supabase's extensions and roles
- **Auth** (GoTrue) for sign-ups, logins, OAuth and magic links
- **PostgREST** for the auto-generated REST API, and **postgres-meta** for Studio
- **Realtime**, **Storage** (with imgproxy for image resizing) and **Edge Runtime** for functions
- **Supavisor** for connection pooling
- **Studio**, the dashboard, behind an API gateway on port 8000
- Optional logging (Logflare and Vector), which enables the log explorer in Studio

Supabase lists minimum requirements of 4 GB RAM, 2 CPU cores and a 40 GB SSD, and recommends 8 GB RAM, 4 cores and 80 GB or more. You can remove services you don't use, such as Realtime or Storage, to save memory.

## How self-hosted differs from Supabase Cloud

According to the [self-hosting overview](https://supabase.com/docs/guides/self-hosting), a self-hosted stack:

- Runs **one project**. Studio has no multi-project or organization view, so each extra project is another stack.
- Is configured mostly through **environment variables**, not dashboard settings.
- Has **no branching, managed backups, point-in-time recovery or Management API**, and lacks some newer platform features such as analytics and vector buckets.
- Is **community-supported** through GitHub, Discord and Reddit, unless you arrange enterprise support.

On the plus side, self-hosted Supabase sends no telemetry, and you have full access to the server and the database.

## The Docker Compose route, at a high level

This outline shows the shape of the install. Use the commands from the [Docker guide](https://supabase.com/docs/guides/self-hosting/docker) for your release, because the docs pin a specific release tag.

```bash
# 1. Get the Docker files for a pinned release
git clone --depth 1 --branch <release-tag> https://github.com/supabase/supabase
mkdir supabase-project
cp -rf supabase/docker/. supabase-project
cd supabase-project
cp .env.example .env

# 2. Generate the Postgres password, API keys and JWT signing keys
sh utils/generate-keys.sh
sh utils/add-new-auth-keys.sh

# 3. Edit .env: SUPABASE_PUBLIC_URL, API_EXTERNAL_URL, SITE_URL,
#    DASHBOARD_USERNAME, DASHBOARD_PASSWORD and the SMTP_* settings

# 4. Pull images and start
docker compose pull
docker compose up -d
docker compose ps   # wait until every service shows "healthy"
```

Studio is then at `http://<your-server>:8000`, protected by the dashboard username and password. Your app connects with the public URL and the publishable key, exactly as it would to a Supabase Cloud project.

Never start the stack with the placeholder values from `.env.example`. They are public, and anyone could use them to sign tokens or log in to your database.

## What you're responsible for afterwards

Supabase's own docs list server maintenance, security hardening, configuration, Postgres maintenance, high availability, backups and monitoring as the self-hoster's job. In practice that breaks down like this.

### TLS and your domain

The default setup serves plain HTTP on port 8000. For production you need HTTPS, not least because OAuth providers generally expect HTTPS callback URLs. Put a reverse proxy such as Caddy or Nginx in front of the gateway, get a certificate (Let's Encrypt works), keep renewals working, and update the URLs in `.env` to `https://`. See [custom domains for Supabase](/guides/supabase-custom-domain) for how domains interact with Auth.

### Secrets and keys

You own the Postgres password, the API keys, the JWT signing keys and several encryption keys (for Realtime, Vault and Storage's S3 access). Keep `.env` out of git, store secrets in a secrets manager, and only ever put the publishable key in client apps. Rotating keys is scripted, but rotating the signing keys signs out active users, so plan it.

### SMTP for auth emails

Sign-up confirmations, magic links and password resets need a real email provider. Set `SMTP_HOST`, `SMTP_PORT`, `SMTP_USER`, `SMTP_PASS`, `SMTP_ADMIN_EMAIL` and `SMTP_SENDER_NAME`, then set up SPF, DKIM and DMARC on your sending domain so the emails don't land in spam.

### Backups and restores

There are no managed backups. At a minimum, run a scheduled `pg_dump` and copy the output off the server. For point-in-time recovery, set up WAL archiving with a tool such as pgBackRest or WAL-G. Storage files live in a Docker volume (or an S3 bucket if you configure one) and need their own backup. Most importantly, test a restore onto a fresh server before you need one. Our [Supabase backups guide](/guides/supabase-backups) covers what a good backup plan looks like.

### Upgrades

Supabase publishes stable self-hosted snapshots roughly monthly. The repository includes an update script that merges new configuration into yours, but read the changelog for breaking changes first and don't mix image versions from different snapshots. Postgres major version upgrades are a separate, bigger job. Also keep the host OS and Docker patched.

### Monitoring

Nobody is watching unless you set it up. You'll want uptime checks on the API, alerts for disk space (a full disk stops Postgres), CPU and memory, and failing containers. Logs are off by default; the optional logging stack or the community [supabase-observability](https://github.com/supabase-community/supabase-observability) project can help.

### Scaling

The Compose setup is one server. You scale by moving to a bigger machine, which means downtime unless you build something more involved. High availability, failover and read replicas are yours to design. A community Kubernetes setup exists for teams who need it.

### Security hardening

Firewall everything except 80 and 443, keep Postgres off the public internet, and put Studio behind a VPN or IP allowlist, since it only has HTTP basic auth. Enable RLS on every exposed table; see [Supabase row level security](/guides/supabase-row-level-security). Patch promptly when security releases come out.

### Features that work differently

Expect differences from the hosted dashboard. Many settings are environment variables rather than toggles, Studio manages one project, and things like branching, PITR and the Management API aren't available. Tools that assume a Supabase Cloud project, such as `supabase link`, may not work against your server. Scheduled jobs work with pg_cron; see [Supabase pg_cron](/guides/supabase-pg-cron).

## A realistic checklist

Before you send real users to a self-hosted Supabase:

- [ ] Server sized at least to Supabase's minimums, with room for database growth
- [ ] All placeholder secrets replaced; `.env` stored in a secrets manager, not git
- [ ] HTTPS via a reverse proxy, with automatic certificate renewal tested
- [ ] `SUPABASE_PUBLIC_URL`, `API_EXTERNAL_URL` and `SITE_URL` set to the HTTPS domain
- [ ] SMTP configured, with SPF, DKIM and DMARC, and a test sign-up email received
- [ ] OAuth providers configured with the new callback URLs
- [ ] Firewall: only 80 and 443 open; Postgres and Studio not publicly reachable
- [ ] RLS enabled and policies reviewed on every table in exposed schemas
- [ ] Nightly database backups copied off the server, plus Storage file backups
- [ ] A restore tested end to end on a fresh machine, with the time it took written down
- [ ] Uptime, disk, CPU and memory alerts going to someone who will act on them
- [ ] An upgrade routine: who reads the changelog, how you test, how you roll back
- [ ] A plan for what happens if the server dies, and how long you can be down

If that list looks fine to you, self-hosting is a good option: it's the cheapest way to run Supabase at the infrastructure level and gives you complete control.

## A middle ground: managed hosting of open-source Supabase

If you want the open-source stack but not the operations work, a managed host sits between self-hosting and Supabase Cloud. [SupaHost](/pricing) is one example. It runs open-source Supabase on a cloud VM dedicated to your account and handles the items above:

- **TLS:** custom domains with automatic Let's Encrypt HTTPS.
- **Auth emails:** sent for you, with editable templates.
- **Backups:** daily database backups (7 or 14 days depending on plan), point-in-time recovery on Pro and Business, and per-project restores. See [/docs#backups](/docs#backups).
- **Monitoring:** health checks every minute with email alerts, and disks that grow as they fill.
- **Many projects:** one instance holds many projects, each with its own database, Auth, Storage, Studio, API URL and keys.

The limits matter, so here they are plainly. SupaHost is in public beta. It has no SLA, no SOC 2, ISO 27001 or HIPAA, no read replicas, no connection pooler, no multi-server failover and no searchable log explorer. Storage files are capped at 50 MB each, there are no image transformations, and Storage files aren't included in the daily backups (you can download them at any time). Edge Functions deploy from the dashboard or over MCP, not with `supabase functions deploy`. Direct Postgres access over an SSH tunnel is only on the Business plan. Plans start at $25 a month; see [/pricing](/pricing).

## Which should you choose?

- **Self-host** if you have ops experience, want full control, or must keep data on your own infrastructure.
- **Use a managed open-source host** if you run several projects and want flat pricing without running servers, and the limits above are acceptable.
- **Stay on Supabase Cloud** if you need compliance certifications, an SLA, read replicas or the full hosted feature set. See [Supabase alternatives](/guides/supabase-alternatives) for other routes.

## FAQ

### Can you self-host Supabase for free?
The software is free and open source under Apache 2.0. You pay for the server, a domain, an email provider and backup storage, plus your own time to run it.

### Is self-hosted Supabase production-ready?
It can be, with work. The Docker Compose setup is the officially supported starting point, but production readiness depends on what you add: HTTPS, real secrets, SMTP, tested backups, monitoring and hardening. Don't use the Supabase CLI's local development stack in production; Supabase says it isn't hardened for that.

### Can I run multiple projects on one self-hosted Supabase?
Not within one stack. Self-hosted Studio manages a single project, so each project needs its own stack, which means more memory and more to maintain.

### Does self-hosted Supabase include Edge Functions and Realtime?
Yes. The Docker setup includes Edge Runtime for functions, Realtime, Storage, Auth and the REST API. Some platform-only features, such as branching and point-in-time recovery, are not included.

### How do I move an existing Supabase Cloud project to my own server?
Dump the database with the Supabase CLI, restore it into your new stack, copy Storage files, redeploy functions and update Auth settings. Our guide on [how to move a Supabase project to another host](/guides/migrate-supabase-project) walks through each step.