Install Supabase on a VPS | Self-Hosted Guide

What is Supabase?

Supabase is an open-source Firebase alternative that provides:

PostgreSQL database - A full Postgres database with real-time subscriptions
Authentication - User sign-ups, logins, OAuth providers, and session management
Storage - File storage with permissions managed through Postgres
Edge Functions - Serverless functions using Deno runtime
Real-time - Listen to database changes and broadcast to connected clients
Studio - A web dashboard for managing your project

By self-hosting Supabase, you maintain full control over your data and avoid vendor lock-in.

System requirements

Before you begin, make sure your VPS meets these requirements:

Resource	Minimum	Recommended
RAM	4 GB	8 GB+
CPU	2 cores	4 cores+
Disk	50 GB SSD	80 GB+ SSD

Supabase runs about 12 Docker containers, so adequate resources are important. For production workloads, we recommend starting with at least 8 GB RAM.

If you don’t need all features, you can disable unused services (like Analytics, Edge Functions, or Storage) to reduce resource requirements.

Before you start

Make sure you have a VPS ready and online on ServerPoint’s ColossusCloud platform. This guide assumes you have:

A ColossusCloud VPS running Ubuntu 24.04 LTS with at least 4 GB RAM
SSH access to your server with root or sudo privileges
Basic familiarity with Linux and Docker
A domain name pointed to your server (recommended for production)

If you haven’t deployed a VPS yet, log into ServerPoint’s Client Portal to create one. Your ColossusCloud VPS will be online in under a minute.

Step 1: Update your system

Start by updating your package lists and installed packages:

sudo apt update && sudo apt upgrade -y

Step 2: Install Docker

Install Docker Engine and Docker Compose:

# Install required packages
sudo apt install -y ca-certificates curl gnupg

# Add Docker's official GPG key
sudo install -m 0755 -d /etc/apt/keyrings
curl -fsSL https://download.docker.com/linux/ubuntu/gpg | sudo gpg --dearmor -o /etc/apt/keyrings/docker.gpg
sudo chmod a+r /etc/apt/keyrings/docker.gpg

# Add the Docker repository
echo \
  "deb [arch=$(dpkg --print-architecture) signed-by=/etc/apt/keyrings/docker.gpg] https://download.docker.com/linux/ubuntu \
  $(. /etc/os-release && echo "$VERSION_CODENAME") stable" | \
  sudo tee /etc/apt/sources.list.d/docker.list > /dev/null

# Install Docker
sudo apt update
sudo apt install -y docker-ce docker-ce-cli containerd.io docker-buildx-plugin docker-compose-plugin

Verify the installation:

docker --version
docker compose version

Step 3: Install Git

If Git isn’t already installed:

sudo apt install -y git

Step 4: Clone the Supabase repository

Get the official Supabase Docker setup:

# Clone the repository (shallow clone for speed)
git clone --depth 1 https://github.com/supabase/supabase

# Create your project directory
mkdir supabase-project

# Copy the Docker files to your project
cp -rf supabase/docker/* supabase-project

# Copy the example environment file
cp supabase/docker/.env.example supabase-project/.env

# Navigate to your project
cd supabase-project

Step 5: Generate secure secrets

This is critical for security. Never use the default example values in production.

Supabase provides a script to generate all required secrets:

sh ./utils/generate-keys.sh

This script will generate and update your .env file with secure values for:

JWT_SECRET - Used to sign authentication tokens
ANON_KEY - Client-side API key with limited permissions
SERVICE_ROLE_KEY - Server-side API key with full access
POSTGRES_PASSWORD - Database password
And several other encryption keys

Review the output and verify the .env file was updated correctly.

Manual configuration (alternative)

If you prefer to configure secrets manually, generate them using these commands:

# Generate a strong database password (letters and numbers only)
openssl rand -base64 32 | tr -dc 'a-zA-Z0-9' | head -c 32

# Generate JWT secret
openssl rand -base64 48

# Generate other required keys
openssl rand -hex 16  # For VAULT_ENC_KEY (exactly 32 chars)
openssl rand -base64 24  # For other keys (at least 32 chars)

Then edit .env and replace all placeholder values.

Step 6: Configure URLs and dashboard access

Edit the .env file to set your domain and dashboard password:

nano .env

Update these essential settings:

# Your public URL (use your domain or IP)
SUPABASE_PUBLIC_URL=http://your-domain.com:8000
API_EXTERNAL_URL=http://your-domain.com:8000

# Your application's URL (if different)
SITE_URL=http://your-domain.com:3000

# Dashboard credentials (change the password!)
DASHBOARD_USERNAME=admin
DASHBOARD_PASSWORD=your-secure-password-here

The dashboard password must include at least one letter.

Step 7: Pull the Docker images

Download all the required Docker images:

docker compose pull

This may take several minutes depending on your connection speed.

Step 8: Start Supabase

Launch all services:

docker compose up -d

Check that all containers are running:

docker compose ps

Wait a minute or two, then verify all services show Up [...] (healthy).

If any service isn’t healthy, check its logs:

docker compose logs <service-name>

For example: docker compose logs analytics

Step 9: Access Supabase Studio

Open your browser and go to:

http://your-server-ip:8000

Or if you configured a domain: http://your-domain.com:8000

You’ll be prompted for credentials. Use the username and password you set in .env (DASHBOARD_USERNAME and DASHBOARD_PASSWORD).

Step 10: Secure your VPS with ServerPoint’s Cloud Firewall

One advantage of running Supabase on ServerPoint’s ColossusCloud is our network-level Cloud Firewall. Unlike software firewalls that run inside your VPS, our Cloud Firewall blocks malicious traffic at the network edge - before it reaches your server.

Configure firewall rules via ServerPoint’s Client Portal

In your Client Portal, navigate to the Firewall section for your VPS and configure these rules:

Port 22 (SSH) - Restrict to your IP addresses only, or keep closed and open only when needed
Port 8000 (Supabase API/Studio) - Open for web access. Consider restricting Studio access to specific IPs
Port 5432 (PostgreSQL via Supavisor) - Only open if you need external database access. Restrict to specific IPs
Port 6543 (PostgreSQL pooled connections) - Same as above

Set the default policy to deny all other incoming traffic.

This enterprise-grade network security is included with every ColossusCloud VPS at no additional cost.

Connecting to your database

Supabase uses Supavisor as a connection pooler. Connect using:

Session mode (like direct Postgres):

postgres://postgres.your-tenant-id:YOUR_PASSWORD@your-domain:5432/postgres

Transaction mode (connection pooling):

postgres://postgres.your-tenant-id:YOUR_PASSWORD@your-domain:6543/postgres

The default tenant ID is your-tenant-id - you can change this in .env.

Accessing the APIs

All APIs are available through port 8000:

REST API: http://your-domain:8000/rest/v1/
Auth API: http://your-domain:8000/auth/v1/
Storage API: http://your-domain:8000/storage/v1/
Realtime: http://your-domain:8000/realtime/v1/
Edge Functions: http://your-domain:8000/functions/v1/

Optional: Configure email (SMTP)

To enable email features like password resets and email confirmations, add SMTP settings to your .env:

SMTP_ADMIN_EMAIL=[email protected]
SMTP_HOST=smtp.yourprovider.com
SMTP_PORT=587
SMTP_USER=your-smtp-username
SMTP_PASS=your-smtp-password
SMTP_SENDER_NAME=Your App Name

Then restart the services:

docker compose down && docker compose up -d

Optional: Add SSL with a reverse proxy

For production, we recommend putting Supabase behind Nginx with SSL. Here’s a basic setup:

sudo apt install -y nginx certbot python3-certbot-nginx

Create an Nginx configuration:

sudo nano /etc/nginx/sites-available/supabase

Add:

server {
    listen 80;
    server_name your-domain.com;

    location / {
        proxy_pass http://localhost:8000;
        proxy_http_version 1.1;
        proxy_set_header Upgrade $http_upgrade;
        proxy_set_header Connection "upgrade";
        proxy_set_header Host $host;
        proxy_set_header X-Real-IP $remote_addr;
        proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for;
        proxy_set_header X-Forwarded-Proto $scheme;
    }
}

Enable the site and get an SSL certificate:

sudo ln -s /etc/nginx/sites-available/supabase /etc/nginx/sites-enabled/
sudo nginx -t
sudo systemctl reload nginx
sudo certbot --nginx -d your-domain.com

After setting up SSL, update your .env URLs to use https://.

Updating Supabase

To update to the latest version:

cd supabase-project

# Pull latest images
docker compose pull

# Restart services
docker compose down && docker compose up -d

Check the Supabase changelog before updating to review breaking changes.

Stopping Supabase

To stop all services:

docker compose down

To stop and remove all data (use with caution):

docker compose down -v

Troubleshooting

Services not starting

Check logs for the problematic service:

docker compose logs <service-name>

Common issues:

Insufficient memory - try disabling unused services
Port conflicts - check if another service is using port 8000 or 5432

Database connection issues

Verify your connection string uses the correct tenant ID and password from .env.

Studio won’t load

Ensure all services are healthy with docker compose ps. The Studio depends on other services being up first.

Disabling unused services

If you don’t need certain features, you can reduce resource usage by removing services from docker-compose.yml:

Logflare and Vector - Analytics and log management
Edge Runtime - Serverless functions
imgproxy - Image processing
Realtime - Real-time subscriptions
Storage - File storage

Comment out or remove the corresponding service sections and their dependencies.

Making Supabase highly available

A single VPS running Supabase is a single point of failure. For production workloads where uptime matters, consider these approaches to add redundancy.

Understanding the challenge

Supabase isn’t a single application - it’s about 12 interconnected services. The critical component is PostgreSQL, which is stateful and requires proper replication. The other services (Auth, REST API, Storage, Realtime) are mostly stateless and easier to scale.

Option 1: Basic redundancy with Cloudflare

The simplest approach uses two VPS instances with Cloudflare handling failover:

Setup:

Primary VPS: Full Supabase installation
Standby VPS: Full Supabase installation with PostgreSQL streaming replication from primary
Cloudflare Load Balancing: Health checks both servers, routes to healthy one

How PostgreSQL streaming replication works:

On your primary server, edit postgresql.conf:

wal_level = replica
max_wal_senders = 3
wal_keep_size = 64MB

And pg_hba.conf:

host replication replicator standby-server-ip/32 md5

On the standby, set up the replica to follow the primary. Supabase’s Docker setup uses a custom PostgreSQL image, so you’ll need to configure replication at the Docker volume level or use an external PostgreSQL cluster.

Failover: If the primary fails, Cloudflare routes traffic to the standby. You manually promote the standby to primary. This isn’t instant, but it’s straightforward.

For details on Cloudflare load balancing, see our guide: Skip the self-hosted load balancer, use Cloudflare instead.

Option 2: PostgreSQL cluster with automatic failover

For automatic database failover, you need a proper PostgreSQL cluster:

Components:

3 PostgreSQL nodes (minimum for quorum-based failover)
Patroni - Manages automatic failover between PostgreSQL nodes
etcd or Consul - Distributed configuration store for Patroni
Supabase services - Run separately, pointing to the PostgreSQL cluster

Architecture:

                    ┌─────────────────┐
                    │   Cloudflare    │
                    │  Load Balancer  │
                    └────────┬────────┘
                             │
         ┌───────────────────┼───────────────────┐
         │                   │                   │
    ┌────▼────┐         ┌────▼────┐         ┌────▼────┐
    │  VPS 1  │         │  VPS 2  │         │  VPS 3  │
    │ Auth,   │         │ Auth,   │         │ Auth,   │
    │ REST,   │         │ REST,   │         │ REST,   │
    │ Storage │         │ Storage │         │ Storage │
    └────┬────┘         └────┬────┘         └────┬────┘
         │                   │                   │
         └───────────────────┼───────────────────┘
                             │
                    ┌────────▼────────┐
                    │   PostgreSQL    │
                    │ Cluster (3 node)│
                    │  with Patroni   │
                    └─────────────────┘

This approach separates the stateless Supabase services from the database, allowing each to scale independently.

Trade-offs:

More complex to set up and maintain
Requires at least 3 VPS instances for PostgreSQL alone
Patroni handles automatic failover in seconds
Best suited if you’re comfortable with PostgreSQL administration

Option 3: Multi-region deployment

For geographic redundancy across data centers:

Primary region (e.g., Amsterdam):

Full Supabase installation with PostgreSQL primary

Secondary regions (e.g., Las Vegas, Singapore):

Supabase services pointing to primary database
PostgreSQL read replicas for read-heavy workloads
Cloudflare geo-steering routes users to nearest region

Considerations:

Writes always go to the primary region (added latency for distant users)
Reads can be served from local replicas
Cross-region replication adds complexity and potential lag
Best for read-heavy applications with global users

Option 4: Kubernetes with HA PostgreSQL

For organizations already using Kubernetes, community Helm charts combine Supabase with HA PostgreSQL:

What it provides:

3+ node PostgreSQL cluster using the Zalando Postgres Operator
Automatic failover with Patroni and Spilo
All Supabase services deployed as Kubernetes pods
Horizontal scaling of stateless services
GitOps compatible (ArgoCD, Flux)

Requirements:

Kubernetes cluster (3+ nodes recommended)
Knowledge of Kubernetes, Helm, and PostgreSQL operations
More infrastructure to manage, but more automation

Search for “Supabase HA Kubernetes Helm chart” for community-maintained options.

Which option should you choose?

Scenario	Recommended Approach
Small to medium production app	Option 1: Two VPS with Cloudflare
Mission-critical with zero downtime	Option 2: PostgreSQL cluster with Patroni
Global user base	Option 3: Multi-region with read replicas
Already using Kubernetes	Option 4: HA Kubernetes deployment
Development or staging	Single VPS is fine

Important notes on self-hosted HA

Complexity increases significantly - Each redundancy layer adds operational burden
Backups are still essential - Replication protects against hardware failure, not data corruption or accidental deletion
Test your failover - Regularly verify that failover actually works
Consider managed Supabase - For truly critical workloads, Supabase’s managed platform handles HA for you

If the complexity of self-hosted HA seems daunting, that’s because it is. For many teams, using Supabase’s managed platform for production and self-hosting for development makes more sense than building your own HA infrastructure.

Official resources

Supabase website - Official site with managed hosting and documentation
Supabase self-hosting docs - Official self-hosting guide
Supabase on GitHub - Source code, Docker setup, and issues
Supabase Discord - Community support and discussions
Supabase YouTube channel - Tutorials, launch weeks, and feature demos

Next steps

Now that Supabase is running on your ServerPoint ColossusCloud VPS, you might want to:

Create your first project and database tables in Studio
Set up authentication providers (Google, GitHub, etc.)
Configure storage buckets for file uploads
Explore Edge Functions for serverless logic
Enable ServerPoint’s VPS snapshot backup service for complete disaster recovery
Read about Cloudflare load balancing for multi-VPS setups

Need more power for your Supabase installation? Upgrading your ColossusCloud VPS takes just a few clicks in the Client Portal - add RAM, CPU cores, or storage without any migration.

Explore our VPS plans across multiple data centers for geographic redundancy.

How to install Supabase on a VPS