Self-Host Supabase on a VPS

Supabase Cloud vs Self-Hosted (Cost Table)

The break-even favours self-hosting once you outgrow starter tiers — but the honest ledger includes the failure modes you now own: an unpatched Postgres, a missed backup verification, an exposed port. Decide with your risk appetite, not just the spreadsheet.

VPS Sizing: What Each Service Consumes

Yes — and sizing starts from what Supabase actually runs. PostgreSQL (the Kong API gateway routes to it), GoTrue for authentication, PostgREST generating the REST API from your schema, Realtime over websockets, Storage with an S3-compatible layer (MinIO), and Studio for the dashboard — all orchestrated by Docker Compose.

Working RAM reality: the official guidance puts self-hosted Supabase at 4 GB minimum, and that floor is honest — Postgres plus the service mesh fits 4 GB for development and light production. 8 GB is the comfortable production tier for small teams, leaving cache headroom for Postgres. Storage: your database size plus object storage growth on NVMe; CPU: two cores minimum, four comfortable.

Step 1: Docker Compose Setup

Step one, deployment: Docker plus Docker Compose on a fresh Ubuntu LTS VPS. Clone the Supabase repository, which ships the docker-compose.yml and a .env.example. Configure the environment: generate strong secrets — JWT signing keys (anon and service_role), a Postgres password, a dashboard access key for Studio, and the internal service keys the compose file marks.

Then docker compose up -d and the full stack comes up on the ports the compose file defines. Verify by opening Studio, creating a table, and exercising an anonymous API call. Two early disciplines: pin the Supabase version you deploy (compose files are versioned), and change every default secret before first exposure — public APIs running on default JWTs are a documented compromise pattern.

Step 2: Environment Secrets, Domain, SSL

Two practical notes on Auth, Storage and Realtime services: it interacts directly with caching and database response, and misconfiguration is the most common cause of 'hosting is slow' tickets. WebJi® support checks it as part of standard migrations.

Step 3: Backups and Upgrade Workflow

Step three — the operational half — is where self-hosting earns or breaks its promise. Backups in three layers: pg_dump on a schedule covering the database, the irreplaceable state; storage objects and your environment files, which hold the secrets that make a restore coherent. And offsite copies of both, pushed to separate infrastructure.

Test the restore once — a backup you have never restored is a hypothesis, not a backup. Upgrades: pin your release, pull the upstream compose updates for a targeted version, read the release notes for breaking changes, snapshot the volumes (your instant rollback), then docker compose pull and up -d. The 3-2-1 backup rule is the pattern to copy.

When to Stay on Supabase Cloud

Stay on Supabase Cloud when the calculus favours convenience: the free and low-cost tiers handle hobby and early-stage projects with zero operations; backups, upgrades and monitoring are theirs. Auth email delivery works out of the box; you scale by sliding a plan.

Move to self-hosting when the drivers are concrete: data residency (an India-located VPS keeps user data in India), cost at scale, custom Postgres extensions the cloud tier restricts, and integration with internal infrastructure. Middle paths exist, but the core question stands: is your team's time worth more than the operational hours a VPS demands? The VPS cost guide prices the self-hosted side in INR.