Blog / Tutorials / Self-Hosting Supabase on a VPS: What You Need to Know

Self-Hosting Supabase on a VPS: What You Need to Know

Self-hosted Supabase gives you a full Postgres-backed backend on your own server. This guide covers the 11-container Docker stack, minimum VPS requirements, deployment steps, and how Contabo fits in.

8 min read
Self-Hosting Supabase on a VPS: What You Need to Know (head image)

In short.

  • Self-hosted Supabase is open-source Supabase Cloud running on your own server via Docker Compose.
  • Minimum: 4 GB RAM, 2 CPU cores. Recommended: 8 GB RAM, 4 cores.
  • The Docker stack runs 11 containers: Postgres, Auth, PostgREST, Realtime, Storage, Studio, and more.
  • Contabo provides the VPS. You run, update, and back up the Supabase stack yourself.

Self-hosted Supabase (a self-hosted Supabase instance you operate on your own infrastructure) gives you a full Postgres-backed backend without a managed subscription. You get the same Auth, Storage, Realtime, and REST API as Supabase Cloud, but the server is yours, the data stays where you put it, and the bill is flat. The open-source project is Apache 2.0 licensed, so there is no per-project or per-seat cost: you pay only for the VPS.

This guide covers what the stack includes, how to deploy it with Docker Compose, how to keep it updated, and what to weigh before choosing to self-host on a Contabo VPS instead of using Supabase Cloud.

What Self-Hosted Supabase Includes

The Supabase Docker Compose configuration spins up 11 containers. Knowing what each one does makes every later problem readable:

  • PostgreSQL: the core database. Everything else wraps it.
  • Auth: JWT-based authentication for sign-ups, logins, magic links, and OAuth.
  • PostgREST: turns your PostgreSQL schema into a RESTful API automatically.
  • Realtime: an Elixir server that listens to PostgreSQL changes and broadcasts them over WebSockets.
  • Storage: a file upload and retrieval API; Postgres handles access permissions, local disk or S3 handles the files.
  • Studio: the browser dashboard. The heaviest single container at idle.
  • API gateway: Envoy by default (Kong available as an optional override). Routes /auth, /rest, /storage to the right service and handles API key authentication.
  • Supavisor: the connection pooler. Manages Postgres connections so your app doesn’t saturate the database.
  • imgproxy: image resizing on-the-fly for files stored in Storage.
  • postgres-meta: a REST API for Postgres management (fetch tables, add roles, run queries).
  • Edge Functions: a Deno runtime for serverless functions that run close to the database.

You can trim the stack. If you don’t need Realtime, Storage, imgproxy, Edge Functions, or Analytics, remove the relevant sections from docker-compose.yml and the idle RAM footprint drops accordingly. The minimum services to get a working backend are PostgreSQL, Auth, PostgREST, and the API gateway.

System requirements

The official Supabase requirements for running the full stack are:

ResourceMinimumRecommended
RAM4 GB8 GB+
CPU2 cores4 cores+
Disk40 GB SSD80 GB SSD+

RAM is the constraint that bites first, because Studio alone is the heaviest single container. Most users running the full 11-container stack on a 4 GB server report hitting the memory ceiling under moderate load. 8 GB gives genuine headroom.

Deploying the Supabase Docker Stack

The official Docker configuration ships with two installation paths. Both land in the same place: a working Supabase stack with all secrets set and services healthy. The difference is how much of that work is automated.

Quick start (Linux)

For most Contabo VPS deployments running Ubuntu or Debian, the quick-start script is the right choice. One command installs Docker if needed, fetches the Docker Compose configuration, generates all secrets, and prompts you for your URLs:

curl -fsSL https://supabase.link/setup.sh | sh

The script supports Debian/Ubuntu and RHEL/CentOS/Fedora. It handles everything the manual path requires you to do yourself: installing prerequisites, generating a secure DASHBOARD_PASSWORD, creating the asymmetric JWT signing key pair, and writing your URLs to .env. You can inspect the script before running at raw.githubusercontent.com/supabase/supabase/refs/heads/master/docker/setup.sh.

Once the script finishes, start the stack:

cd supabase-project && \
sh run.sh start

View your generated credentials at any time with:

sh run.sh secrets

Manual installation

If you’re not on a supported Linux distribution, or you want explicit control over each step, clone the repository directly. The commands below pin to a specific release tag, so replace self-hosted/v0.8.1 with the latest tag from the Supabase releases page when you run this.

git clone --depth 1 --branch self-hosted/v0.8.1 https://github.com/supabase/supabase
mkdir supabase-project
cp -rf supabase/docker/. supabase-project
cd supabase-project && cp .env.example .env
printf 'ref=self-hosted/v0.8.1\n' > .supabase-version
docker compose pull

Never start the stack with the example secrets. Before your first run.sh start, generate all secrets with the bundled scripts:

sh utils/generate-keys.sh
sh utils/add-new-auth-keys.sh

Then set your external URLs in .env:

SUPABASE_PUBLIC_URL=https://your-domain.com:8000
API_EXTERNAL_URL=https://your-domain.com:8000/auth/v1
SITE_URL=https://your-domain.com

Starting with default secrets and rotating them later causes the connection pooler to hang with no useful error. Set them once before first boot.

Bring the stack up:

sh run.sh start

All services should reach healthy status within a minute or two. Verify with:

docker compose ps

Studio and all APIs are available through the API gateway on port 8000 by default: http://your-server-ip:8000. For production, place a reverse proxy in front and terminate TLS there. The Supabase docs maintain a dedicated HTTPS configuration guide covering Caddy and Nginx setup in full.

Why Self-Host Supabase on Contabo Instead of Supabase Cloud

Self-hosting on a Contabo VPS makes sense for three kinds of project: those with data residency requirements, those running predictable workloads where a flat monthly rate is cheaper than consumption billing, and those that need full control over the database and stack version.

Data residency. Contabo offers Hub Europe, our EU data center, with data processing under EU law. If your project stores personal data subject to GDPR, keeping everything in a Contabo EU data center and running your own Postgres instance means you control where the data lives and who can access it, with no dependency on a third-party backend.

Cost predictability. Supabase Cloud’s free tier is generous for development, but production workloads are priced on database size, egress, and active users. A Contabo Core VPS gives you a flat monthly rate regardless of how many API calls your app makes. For applications with steady traffic, a fixed-price server often works out cheaper than consumption billing once you pass the free tier limits.

Stack ownership. On a self-hosted instance, you choose the Postgres version, run your own extensions, and control the upgrade schedule. You can also run multiple projects on one server, which Supabase Cloud prices per project.

Contabo provides the VPS and the network. You run the Supabase stack, apply updates, configure backups, and respond to failures. Supabase does not provide support for self-hosted instances. If you are not comfortable managing a Linux server and Docker Compose deployments, Supabase Cloud might be the better starting point.

Keeping the stack up to date

Supabase publishes stable Docker Compose snapshots roughly once a month. The update.sh script handles in-place upgrades: it pulls the latest self-hosted/v* configuration and merges it over your files with a three-way merge, so local changes to docker-compose.yml are preserved where possible.

sh update.sh

Before applying an update, check the self-hosted changelog for breaking changes. After updating, restart the stack:

sh run.sh start

To update or roll back a single service without touching the rest, update the image tag for that service in docker-compose.yml, then run:

sh run.sh pull
sh run.sh recreate studio

Replace studio with the service name you want to update. The rest of the stack stays up during the operation.

Choosing the right Core VPS plan for Supabase

For a development or staging instance with a trimmed-down stack (no Analytics, Edge Functions optional), a Core VPS with 8 GB RAM handles the load comfortably. For a production instance running the full 11-container stack under real traffic, 12 GB or more is the safer starting point.

Contabo Core VPS plans start at 4 vCPU cores and 8 GB RAM, scaling up through 12 GB and 24 GB options. All plans include unlimited traffic (fair use policy) and the Contabo Firewall at no extra cost. Check the current pricing and availability at the Contabo VPS page.

Enable Auto Backup from the Customer Control Panel to protect your Postgres data with daily off-server incremental backups. For a self-hosted database you are managing yourself, backups are not optional.

FAQ: Self-Hosting Supabase

Is self-hosted Supabase free?

The Supabase open-source project is licensed under Apache 2.0 and free to use. You pay only for the VPS you run it on. There is no per-seat fee, no egress charge, and no license cost. Supabase Cloud’s managed free tier is an alternative for smaller projects, but for self-hosted deployments the only recurring cost is the server itself.

Does Contabo manage my self-hosted Supabase instance?

No. Contabo manages the VPS hardware, network, and hypervisor. Everything running inside the server, including the Docker Compose stack, the Postgres database, and all Supabase services, is your responsibility. That means applying updates, rotating secrets, configuring backups, and responding to container failures. Supabase does not offer support for self-hosted instances.

What’s the minimum VPS size for self-hosted Supabase?

The official Supabase minimum for the full stack is 4 GB RAM, 2 CPU cores, and 40 GB SSD. In practice, many users find the full 11-container stack runs tight on 4 GB under real load, since Studio alone is the heaviest single container. The recommended self-hosted Supabase spec is 8 GB RAM, 4 cores, and 80 GB SSD.

Can I run multiple Supabase projects on one VPS?

Yes, with caveats. Each project needs its own Postgres database and Supabase services, meaning separate Docker Compose stacks on different ports. A server with 24 GB RAM can typically run two or three full stacks in parallel, depending on traffic. Most teams keep one project per server for production and share a single server for development environments.

How do I back up my self-hosted Supabase database?

Two approaches cover most cases. Use pg_dump on a schedule to export Postgres to a compressed file and ship it off-server. Additionally, enable Contabo Auto Backup from the Customer Control Panel for daily incremental VPS snapshots. Combining both is practical for production: database exports give you point-in-time restores, VPS snapshots give you full-server rollback.

Share 𝕏 in