Self-Hosted Supabase on DigitalOcean: A Complete Guide

DigitalOcean sits in a sweet spot for self-hosted Supabase: cheaper than AWS, more familiar than Hetzner for US-based teams, and with S3-compatible object storage (Spaces) built into the same bill. If your Supabase Cloud invoice keeps creeping past what a $48/month droplet could handle, this guide walks through the full deployment — droplet sizing, Docker setup, firewall rules, SSL, and backups — using the same core process as our general step-by-step installation guide, adapted to DigitalOcean specifics.

We already have dedicated guides for Hetzner Cloud and AWS EC2. This one completes the set for the provider that most indie developers and small teams reach for first.

Why DigitalOcean (and Why Not)

Honest trade-offs first, because they matter:

For:

Predictable pricing. A droplet costs what the pricing page says. No surprise egress line items until you pass 4–5 TB of included transfer, which a typical Supabase backend won't.
Spaces is genuinely convenient. S3-compatible storage in the same account and region as your droplet, $5/month for 250 GB. That's your backup target and your Storage backend sorted without a second vendor.
US and EU regions with good peering. If your users are in North America, DigitalOcean's NYC and SFO regions will beat Hetzner's Falkenstein latency by 80–100 ms.

Against:

Price per GB of RAM is roughly 2x Hetzner. A 8 GB/4 vCPU droplet runs about $48/month; Hetzner charges around half that for comparable specs. If every dollar counts and EU latency is acceptable, Hetzner wins on raw value — our VPS provider comparison covers this in depth.
Droplet snapshots are not backups. More on this below — it's the mistake we see most often.

Sizing Your Droplet

The full Supabase stack runs a dozen containers: Postgres, the API gateway, Auth, PostgREST, Realtime, Storage, Studio, and supporting services. Our system requirements call for a practical minimum of 4 GB RAM, and that holds on DigitalOcean:

Droplet	Specs	Price	Verdict
Basic 2 GB	1 vCPU / 2 GB	~$12/mo	Too tight — OOM kills under load
Basic 4 GB	2 vCPU / 4 GB	~$24/mo	Fine for side projects and staging
Basic 8 GB	4 vCPU / 8 GB	~$48/mo	The production sweet spot
Premium 16 GB	8 vCPU / 16 GB	~$96/mo	Multiple projects or heavy Realtime use

Choose a Premium (NVMe) droplet if your workload is query-heavy — Postgres is disk-bound long before it's CPU-bound. If you're determined to run on 2 GB anyway, our guide to running Supabase on low-memory servers covers the swap and service-trimming tricks that make it survivable.

Step 1: Create and Prepare the Droplet

Create an Ubuntu 24.04 LTS droplet with SSH key authentication (never password auth). Then the standard preparation:

# Update and install Docker
apt update && apt upgrade -y
curl -fsSL https://get.docker.com | sh

# Create a non-root user for the deployment
adduser supabase
usermod -aG docker supabase

Add a reserved IP in the DigitalOcean panel before you configure DNS. It's free while assigned to a droplet, and it means you can rebuild or resize the droplet later without touching DNS records.

Step 2: Deploy the Supabase Stack

Pull the official self-hosting setup:

git clone --depth 1 https://github.com/supabase/supabase
cd supabase/docker
cp .env.example .env

Before starting anything, replace every default secret in .env — POSTGRES_PASSWORD, JWT_SECRET, ANON_KEY, SERVICE_ROLE_KEY, DASHBOARD_PASSWORD. The example file ships with publicly known values, and internet-facing databases with default credentials get found within hours, not days. Our environment variables guide explains what each one does and how to generate the JWT-derived keys correctly.

Then:

docker compose pull
docker compose up -d

One timely note: as of the week of August 9, 2026, Supabase's self-hosted stack has swapped its default API gateway from Kong to Envoy. If you customized kong.yml on a previous deployment or relied on Kong's HTTPS listener, read our Kong-to-Envoy migration prep guide before upgrading an existing instance. Fresh deployments from current master get Envoy by default and need no action.

For hardening beyond the defaults — restarting policies, resource limits, log rotation — see Docker Compose production best practices.

Step 3: Lock Down the Network with Cloud Firewalls

DigitalOcean's Cloud Firewalls are free and enforced outside the droplet, which means a misconfigured ufw or a container publishing a port with raw iptables rules (which Docker loves to do) can't accidentally expose Postgres. Create a firewall with exactly these inbound rules:

TCP 22 — your IP only, or better, a VPN range
TCP 80/443 — all sources (for the API gateway and SSL issuance)
Nothing else. Not 5432, not 8000, not 3000.

If you need direct Postgres access for a BI tool or migration scripts, tunnel over SSH or use a private network — never open 5432 to the world. Port 3000 (Studio) deserves particular caution; an exposed Studio dashboard is full admin access to your database.

Step 4: Domain and SSL

Point an A record at your reserved IP, then put a reverse proxy with automatic Let's Encrypt certificates in front of the stack. Caddy is the least-effort option on a single droplet; if you're running Supascale, it handles custom domain binding and SSL issuance for you, including per-project subdomains when you host more than one instance on the same server.

Step 5: Backups — Snapshots Are Not Enough

This is where most DigitalOcean deployments go wrong. Droplet snapshots (20% of droplet cost/month) feel like a backup solution. They aren't:

Snapshots of a running Postgres are crash-consistent, not application-consistent. Restoring one is equivalent to yanking the power cord — usually recoverable, occasionally not, never guaranteed.
They live in the same account. A compromised API token or a billing lapse takes your backups down with your server.
Restore granularity is the whole droplet. You can't recover one deleted table from Tuesday.

The right setup is logical database backups (pg_dump) plus Storage file backups, shipped to a Spaces bucket — ideally in a different region than your droplet. Spaces speaks the S3 API, so anything that targets S3 works with it. Supascale's automated backups do exactly this on a schedule, with one-click restore, and include your Storage files — the piece almost everyone forgets, as we covered in the forgotten piece of Supabase backups.

Keep snapshots as a convenience layer for fast full-server rollback before risky upgrades. Just don't let them be your only copy.

What It Actually Costs

A realistic production setup for a small SaaS:

Item	Monthly
Basic 8 GB droplet	$48
Spaces (backups + Storage)	$5
Reserved IP	$0 (while assigned)
Cloud Firewall	$0
Total	~$53/mo

Compare that to Supabase Cloud Pro at $25/month plus compute add-ons once you outgrow the starter instance — a comparable dedicated 8 GB compute tier on Cloud costs well over $100/month before storage and egress. The trade is your time: upgrades, monitoring, and backup verification become your job. That operational overhead is the honest cost of self-hosting, and it's the part worth automating. Supascale's one-time license (from $99, unlimited projects on your own servers) exists precisely to close that gap without reintroducing a monthly platform fee.

Conclusion

DigitalOcean is a solid, unexciting choice for self-hosted Supabase — and unexciting is what you want from infrastructure. Pick an 8 GB Premium droplet for production, enforce access with Cloud Firewalls, front the stack with automatic SSL, and ship application-consistent backups to Spaces in another region rather than trusting snapshots. Do those four things and you'll have a deployment that's boring in the best possible way: predictable in cost, recoverable in failure, and entirely yours.