How to Self-Host Supabase: The Complete Docker & Coolify Guide (2026)

What you actually get when you self-host Supabase

Supabase is an open-source backend platform built around PostgreSQL. Instead of stitching together a database, authentication service, file storage layer, REST API and realtime system yourself, Supabase packages these pieces into one developer-friendly stack.

When you use the hosted Supabase service, the company handles infrastructure, upgrades, high availability, backups and many operational details. When you self-host, the software is yours to run, but so are the responsibilities. That tradeoff is the entire point: more control, more flexibility, and potentially lower infrastructure cost, in exchange for becoming your own operations team.

What the server needs

For a production-oriented installation, I recommend starting with at least 4 GB of RAM, 2 vCPUs and 40 GB of SSD storage. Supabase currently documents 4 GB RAM / 2 cores as a practical minimum and recommends more for heavier workloads. The stack contains multiple containers, so tiny 1 GB instances are not realistic production targets.

You should also have a domain or subdomain available. A setup such as supabase.yourdomain.com is much cleaner than exposing the service on a raw IP address and port.

Step 1: Prepare your VPS

Start with a clean Ubuntu server. Connect over SSH, update the package index and install current security updates before putting anything public on the machine.

sudo apt update
sudo apt upgrade -y

For additional hardening, create a non-root administrative user, use SSH keys instead of passwords where possible, disable direct root login, and keep your SSH daemon and operating system patched.

sudo adduser deploy
sudo usermod -aG sudo deploy

Step 2: Install Docker and Docker Compose

The recommended route for self-hosting Supabase is Docker. If Docker is not installed yet, the cleanest approach is to follow Docker’s current Ubuntu installation instructions rather than relying on an old copy-and-paste snippet that may age badly.

After installation, confirm both Docker and the Compose plugin are available:

docker --version
docker compose version

If both commands return versions successfully, you are ready for the Supabase stack.

Step 3: Download the official Supabase Docker configuration

You do not need the entire Supabase monorepo. You mainly need the official Docker folder and its Compose configuration.

git clone --filter=blob:none --no-checkout --depth 1 https://github.com/supabase/supabase
cd supabase
git sparse-checkout set docker
git checkout
cd docker
cp .env.example .env

The final command creates your real environment file from the provided example. This is where many installations go wrong: people immediately run docker compose up -d. Do not do that yet.

Step 4: Set every critical secret before the first boot

The sample environment file is not production-ready. Replace demonstration credentials and generated placeholders before the database and supporting services initialize.

The most important values include your PostgreSQL password, JWT secret, API keys, dashboard credentials, vault encryption key and application secret base.

POSTGRES_PASSWORD=replace-with-a-long-random-password
JWT_SECRET=replace-with-a-long-random-secret
ANON_KEY=your-generated-anon-key
SERVICE_ROLE_KEY=your-generated-service-role-key

DASHBOARD_USERNAME=admin
DASHBOARD_PASSWORD=replace-with-a-strong-dashboard-password

VAULT_ENC_KEY=replace-with-a-secure-key
SECRET_KEY_BASE=replace-with-a-long-secure-secret

Your anonymous and service-role API keys are tied to the JWT signing configuration. Treat the SERVICE_ROLE_KEY like an administrative credential: it should never be exposed in front-end JavaScript or published inside a public repository.

You can generate random material from the command line with OpenSSL:

openssl rand -hex 32
openssl rand -base64 48

Supabase also provides key-generation tooling in its official self-hosting resources. Use the current official method when generating JWT-related keys so the values match the version of the stack you are deploying.

Step 5: Pull the images and start Supabase

docker compose pull
docker compose up -d

Give the containers time to initialize, then inspect the stack:

docker compose ps

If one service is unhealthy, inspect its logs instead of repeatedly restarting everything:

docker compose logs --tail=150 SERVICE_NAME

Once the gateway and Studio are healthy, you can initially test access through your server IP and the gateway port. Treat this as a temporary verification step, not the final public configuration.

Step 6: Turn on Row Level Security before exposing real data

Supabase’s database API is powerful because your tables can become accessible through REST almost immediately. That also means you must understand Row Level Security (RLS).

RLS lets PostgreSQL decide which rows a given user is allowed to read, insert, update or delete. It is one of the main security boundaries in a Supabase application. When you create application tables, enable RLS and define policies before trusting the public API with production information.

alter table public.profiles enable row level security;

A policy might allow a signed-in user to read only his or her own profile:

create policy "Users can read their own profile"
on public.profiles
for select
to authenticated
using ((select auth.uid()) = user_id);

Step 7: Configure Auth email so signups actually work

A self-hosted Supabase installation does not magically provide a production email-delivery service. If your app uses email confirmation, magic links, password recovery or email-based account changes, configure a real SMTP relay.

SMTP_HOST=smtp.your-provider.com
SMTP_PORT=587
SMTP_USER=your-smtp-user
SMTP_PASS=your-smtp-password
[email protected]
SMTP_SENDER_NAME=Your App

After changing SMTP values, recreate or restart the Auth service according to the current Compose service names in your installation.

docker compose up -d auth

Test the entire flow with a real signup: create an account, receive the confirmation message, click the link and verify that the user can sign in. A dashboard that loads successfully does not prove Auth email is working.

Step 8: Understand database connection pooling

Modern Supabase self-hosting includes a connection pooler. This matters because your application may not connect directly to the underlying PostgreSQL process from outside the Docker network. Instead, database connections are mediated by the pooler.

In general, you will encounter two patterns:

The exact connection-string format and tenant identifier can change between versions, so copy the current values from your self-hosted configuration or Supabase documentation instead of relying on a years-old tutorial.

Step 9: Put HTTPS in front and close unnecessary ports

Once the stack works internally, give it a real domain and TLS certificate. A reverse proxy such as Caddy, Traefik, Nginx Proxy Manager or Coolify’s built-in proxy can terminate HTTPS and forward requests to Supabase.

With Caddy, the configuration can be very small:

supabase.example.com {
    reverse_proxy 127.0.0.1:8000
}

Then update the relevant public URLs in your environment configuration so authentication links and redirects use your real HTTPS domain.

SUPABASE_PUBLIC_URL=https://supabase.example.com
API_EXTERNAL_URL=https://supabase.example.com
SITE_URL=https://your-app.com

The next task is even more important: stop publishing database and internal service ports to the entire internet unless you intentionally need remote access.

At the host level, a simple firewall policy might allow only SSH, HTTP and HTTPS:

sudo ufw allow OpenSSH
sudo ufw allow 80/tcp
sudo ufw allow 443/tcp
sudo ufw enable
sudo ufw status

If you need administrative database access remotely, an SSH tunnel is generally safer than leaving PostgreSQL open to the world.

Step 10: Build a backup you can restore

A backup is not proven until you restore it. For Supabase, think about at least three separate things: the PostgreSQL database, uploaded Storage objects, and the configuration/secrets required to rebuild the stack.

Database dump

docker exec supabase-db pg_dumpall -U supabase_admin > supabase-db.sql

Storage files

Your deployment may keep data inside bind-mounted directories. When archiving Storage data, preserve filesystem metadata and extended attributes if your current Storage backend depends on them.

tar --xattrs --xattrs-include='*' \
  -czf supabase-storage.tgz \
  -C volumes/storage .

Configuration

Keep an encrypted backup of the files required to reproduce the deployment, including your Compose configuration, environment variables, reverse-proxy rules and any custom SQL migrations.

Step 11: Update Supabase without guessing

Self-hosting means you decide when to update. That is useful, but it also means you are responsible for reading release notes and understanding what is changing.

For routine container updates, the general pattern is to back up first, review image/version changes, pull updated images and recreate the affected services.

docker compose pull
docker compose up -d

Do not treat a PostgreSQL major-version jump like a normal container refresh. Major database upgrades are migrations and deserve their own tested plan.

Running Supabase on Coolify instead

If you already use Coolify, it can make domains, TLS certificates, service deployment and application management more comfortable. You have two broad choices: use a Supabase template supplied by the platform, or deploy the official Supabase Docker Compose as a repository-based application.

The repository approach is attractive because it keeps you closer to the current upstream Supabase configuration. However, Compose files that rely on relative bind mounts and large sets of environment variables can behave differently inside a deployment platform. Make sure the deployed repository files remain available at runtime and fill required variables before the first deployment.

Is self-hosting Supabase actually cheaper?

Sometimes. If you already operate a VPS for other applications and have spare capacity, adding Supabase may be inexpensive. If you rent a dedicated 4–8 GB server solely for Supabase, the monthly infrastructure bill may be close to the cost of a managed plan once you add backups, monitoring and your own time.

Self-host because you value control, predictable infrastructure, data locality, custom networking or the learning experience—not because Docker magically removes operational work.

My recommended production checklist

• Use a server with at least 4 GB RAM for a serious installation.
• Generate unique secrets before the first startup.
• Never expose the service-role key in front-end code.
• Enable RLS and create policies for every application table.
• Configure a real transactional SMTP provider.
• Serve the public gateway through HTTPS.
• Restrict database and internal service ports.
• Keep the operating system and Docker patched.
• Back up PostgreSQL, Storage and configuration.
• Perform a full restore test before you trust the backup.
• Review release notes before upgrades.
• Monitor disk space, memory, container health and database growth.

Frequently Asked Questions

Final thoughts

Getting Supabase to start is the easy part. Running it responsibly is about everything around the containers: secrets, network exposure, HTTPS, authorization policies, transactional email, upgrades, monitoring and recovery.

If you want complete control over your backend and you are comfortable taking ownership of server operations, self-hosting Supabase is a powerful option. If your main goal is simply to ship an application quickly without becoming the database and infrastructure administrator, the managed Supabase platform can still be the better deal.