How to self-host Supabase in 2026: the complete guide

Why self-host Supabase

Supabase became the default backend of the AI-builder era — it's what Lovable wires your app to, what Cursor-built projects reach for, what “add a database and login” usually means in 2026. The hosted cloud is excellent, with a free tier that covers small projects. So why run it yourself?

• Your data, your server. Compliance requirements, customer contracts, or plain principle — some data shouldn't live in a third-party cloud, no matter how good.

• Fixed costs at scale. Cloud pricing grows with usage; a $10–20/month VPS runs the full stack for as many projects as it can hold.

• No pausing, no limits. Free-tier cloud projects pause after inactivity. Your own instance never does, and row limits are whatever your disk allows.

• It's genuinely open source. The entire platform — Postgres, Auth, Storage, Realtime, Edge Functions — ships as a Docker Compose stack, maintained by Supabase itself.

The honest counterweight: self-hosted Supabase is the most demanding app in our self-host series — a multi-service stack, not a single container. If you've never run Docker before, start with something gentler like Uptime Kuma and come back.

What you need

• A server: a VPS with at least 4 GB RAM and 2 CPU cores — 8 GB and 4 cores if real users will touch it. Hetzner, DigitalOcean, or Vultr in the $10–25/month range fit.

• Docker + Docker Compose installed on it.

• 10 GB+ free disk, growing with your data.

• A domain or subdomain (like supabase.yourapp.com) for HTTPS access — required if you'll use OAuth logins.

• 30–60 minutes — the official quickstart says under 30; budget the hour for the security steps below.

Step 1: Get the stack running

Supabase maintains the official Docker Compose setup in its main repository. On your server:

# Get the code
git clone --depth 1 https://github.com/supabase/supabase
cd supabase/docker

# Copy the example environment file
cp .env.example .env

# Pull the latest images
docker compose pull

# Start everything in the background
docker compose up -d

# Get the code
git clone --depth 1 https://github.com/supabase/supabase
cd supabase/docker

# Copy the example environment file
cp .env.example .env

# Pull the latest images
docker compose pull

# Start everything in the background
docker compose up -d

# Get the code
git clone --depth 1 https://github.com/supabase/supabase
cd supabase/docker

# Copy the example environment file
cp .env.example .env

# Pull the latest images
docker compose pull

# Start everything in the background
docker compose up -d

# Get the code
git clone --depth 1 https://github.com/supabase/supabase
cd supabase/docker

# Copy the example environment file
cp .env.example .env

# Pull the latest images
docker compose pull

# Start everything in the background
docker compose up -d

After a few minutes, docker compose ps should show every service running. The stack includes Postgres itself, the API gateway (Kong), Auth, Storage with image resizing, Realtime, Edge Functions, the Supavisor connection pooler, and Studio — the dashboard you know from the cloud — reachable on port 8000.

Do not open it to the internet yet. Right now it's running with published demo credentials.

Step 2: The security steps everyone skips

The example .env ships with demo secrets that are publicly documented — everyone who's read the Supabase docs knows your JWT secret, API keys, and dashboard password until you change them. This is the single most common self-hosted Supabase mistake, and scanners actively look for it.

In your .env, replace at minimum:

• POSTGRES_PASSWORD — a long random password for the database superuser

• JWT_SECRET — at least 40 random characters; everything trusts tokens signed with this

• ANON_KEY and SERVICE_ROLE_KEY — must be regenerated as JWTs signed with your new secret. Supabase's docs include a generator for both — don't hand-edit these

• DASHBOARD_USERNAME / DASHBOARD_PASSWORD — the Studio login; the default is supabase / this_password_is_insecure_and_should_be_updated, which says it all

• SITE_URL and API_EXTERNAL_URL — set to your real domain so auth emails and redirects point to the right place

Then restart the stack to apply: docker compose down followed by docker compose up -d.

Step 3: HTTPS with a reverse proxy

For production — and for OAuth providers, which require it — put a reverse proxy with a TLS certificate in front of the API gateway. Caddy is the least-effort option because certificates are automatic:

# Caddyfile
supabase.yourapp.com {
    reverse_proxy localhost:8000
}

# Caddyfile
supabase.yourapp.com {
    reverse_proxy localhost:8000
}

# Caddyfile
supabase.yourapp.com {
    reverse_proxy localhost:8000
}

# Caddyfile
supabase.yourapp.com {
    reverse_proxy localhost:8000
}

Point your subdomain's DNS at the server, start Caddy, and Let's Encrypt issues the certificate on first request. Nginx with certbot works just as well if you already run it — the pattern is identical to our free SSL setup guide.

Optionally, restrict Studio (the dashboard) to your IP or a VPN — it's an admin panel, and the internet doesn't need to see it.

Step 4: Connect your app

From your app's perspective, a self-hosted Supabase is identical to the cloud — two environment variables change:

SUPABASE_URL=https://supabase.yourapp.com
SUPABASE_ANON_KEY=your-new-anon-key

SUPABASE_URL=https://supabase.yourapp.com
SUPABASE_ANON_KEY=your-new-anon-key

SUPABASE_URL=https://supabase.yourapp.com
SUPABASE_ANON_KEY=your-new-anon-key

SUPABASE_URL=https://supabase.yourapp.com
SUPABASE_ANON_KEY=your-new-anon-key

Every Supabase client library — and every AI-built app that uses one — picks up the new backend with no code changes. If your app came from Lovable, this is the same pair of values it asked for during setup; swap them and the app talks to your server instead of the cloud.

Step 5: Backups, updates, and the maintenance reality

• Backups. A nightly pg_dump shipped off the server is the minimum; storage files (user uploads) need copying too. Test a restore once — an untested backup is a hope, not a backup.

• Updates. docker compose pull && docker compose up -d on a schedule, after reading release notes — Postgres major versions and Auth changes occasionally need migration steps.

• Monitoring. Watch RAM (the stack is hungry) and disk (databases only grow). A free Uptime Kuma instance covers the basics.

• Trimming. If you don't use Realtime, Analytics (Logflare), or Edge Functions, remove those services from docker-compose.yml — meaningfully lower RAM use on small servers.

Self-hosted vs Supabase Cloud: the honest comparison

Self-hosting wins on: data location and control, fixed costs (one VPS, many projects), no project pausing, no row or storage tiers — your disk is the limit.

Cloud wins on: zero maintenance, one-click upgrades, point-in-time recovery, branching, and dashboard features that arrive in the cloud first and reach self-hosted later. The free tier genuinely covers hobby projects, and the $25/month Pro tier buys a lot of not-thinking-about-servers.

The realistic decision: self-host when data control or multi-project economics demand it, and when someone (you) will actually do the maintenance. Otherwise the cloud is the better engineering decision, not a compromise.

Where your app fits in this picture

Supabase — cloud or self-hosted — is only the backend. The app itself still needs hosting, and that's the part livemy.app handles: connect the GitHub repo or drop the ZIP from Lovable, Cursor, or Bolt, paste your two Supabase environment variables, and the app is live on your domain with SSL and monitoring. Free tier to start; Maker $20/month flat.

Backend on your server, app on flat-rate hosting, connected by two env vars — a clean separation that keeps both replaceable.

→ Start free on livemy.app · No credit card · Works with cloud and self-hosted Supabase alike.

FAQ

Is self-hosted Supabase free?

The software, entirely — it's open source. The real costs: a VPS with at least 4 GB RAM ($10–25/month) and your maintenance time. Multiple projects on one server make the math attractive; a single hobby project is usually cheaper on the cloud free tier.

What are the minimum requirements to self-host Supabase?

4 GB RAM and 2 CPU cores minimum, 8 GB RAM and 4 cores for production, 10 GB+ disk, plus Docker and Docker Compose. Trimming unused services (Analytics, Realtime, Edge Functions) from the compose file lowers the floor.

Is self-hosted Supabase the same as the cloud version?

The core — Postgres, Auth, Storage, Realtime, APIs — is the same code. The cloud adds managed extras: automated backups with point-in-time recovery, branching, usage dashboards, and some features that reach self-hosted later. Client libraries work identically against both.

Can my Lovable or AI-built app use self-hosted Supabase?

Yes — swap SUPABASE_URL and SUPABASE_ANON_KEY in your app's environment variables and every Supabase client library follows. Host the app itself on livemy.app and the env var swap is a UI field, not a config file.

What's the biggest self-hosted Supabase mistake?

Running with the example secrets. The demo JWT secret, API keys, and dashboard password in .env.example are public knowledge — leaving any of them is an open door. Generate fresh secrets before the server faces the internet, not after.

Read next

• How to self-host n8n in 2026: the complete guide

• How to self-host NocoDB in 2026: Airtable alternative

• How to host a Lovable app outside Lovable in 2026

• How to self-host Uptime Kuma in 2026: free monitoring + status page