Deploy Supabase on ServerMO: Secure Self Hosted Firebase

Phase 2: Generate Cryptographic Secrets

The most critical security failure developers make is ignoring the placeholder secrets. If you deploy using the default JSON Web Token keys anyone on the internet can forge an administrative token and commandeer your infrastructure. We must generate mathematically secure cryptographic keys immediately.

# Execute the official secret generation script
sh utils/generate-keys.sh

# Inject the newly minted asymmetric keys into your environment
sh utils/add-new-auth-keys.sh

After generating these keys open your environment file and update the public domain parameters so authentication callbacks route correctly back to your users.

# Edit your environment configuration
nano .env

# Modify these specific lines matching your final production domain
SITE_URL=https://supabase.yourdomain.com
API_EXTERNAL_URL=https://supabase.yourdomain.com

Phase 3: Fix the Docker Firewall Bypass

Docker automatically alters Linux networking rules to route traffic into containers. This means if you use a standard firewall to block port 5432 but the deployment file exposes it the port remains wide open to global attackers. You must explicitly instruct the service to bind these critical ports strictly to your local machine loopback.

# Open the main compose configuration
# nano docker-compose.yml

# Find the Kong API gateway service and modify the ports
  kong:
    ports:
      # SECURE: Bound exclusively to localhost
      - 127.0.0.1:${KONG_HTTP_PORT}:8000
      - 127.0.0.1:${KONG_HTTPS_PORT}:8443

# Find the Studio dashboard service and secure it
  studio:
    ports:
      - 127.0.0.1:${STUDIO_PORT}:3000

# Find the Database service and ensure it is not globally exposed
  db:
    ports:
      - 127.0.0.1:${POSTGRES_PORT}:5432

Phase 4: Initialize the Supabase Stack

With your cryptographic secrets secured and your container networking safely bound to localhost you can now pull the massive microservice architecture. This stack includes the Realtime engine GoTrue authentication and the robust PostgREST server.

# Pull the latest container images from the registry
docker compose pull

# Execute the entire infrastructure stack in detached mode
docker compose up -d

# Verify all fifteen containers achieved a healthy operational state
docker compose ps

Phase 5: Configure Exact Nginx Routing

Since we securely locked all containers to localhost external users cannot access your platform yet. We must deploy an Nginx reverse proxy to intercept public traffic. Many amateur tutorials incorrectly route all API requests through an arbitrary sub directory structure causing instant 404 failures because the official client software development kits expect exact root level endpoints.

Furthermore failing to inject WebSocket upgrade headers directly into the Kong gateway block will instantly murder your Realtime database connections.

# Install the web server and certificate provisioning tools
sudo apt install nginx certbot python3-certbot-nginx -y

# Create the proxy configuration file
sudo nano /etc/nginx/sites-available/supabase

Paste the following enterprise routing configuration ensuring WebSockets upgrade properly and the client IP addresses forward accurately for rate limiting.

server {
    listen 80;
    server_name supabase.yourdomain.com;

    # Route Studio Dashboard
    location / {
        proxy_pass http://127.0.0.1:3000;
        proxy_set_header Host $host;
    }

    # CRITICAL: Route exactly how the Client SDK expects utilizing regular expressions
    location ~ ^/(rest|auth|realtime|storage)/v1/ {
        proxy_pass http://127.0.0.1:8000;
        proxy_set_header Host $host;
        
        # Forward true client identity for secure rate limiting
        proxy_set_header X-Real-IP $remote_addr;
        proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for;
        
        # CRITICAL: Prevent the Realtime WebSocket from dropping
        proxy_set_header Upgrade $http_upgrade;
        proxy_set_header Connection "Upgrade";
        
        # Maintain persistent idle connections for live database subscriptions
        proxy_read_timeout 86400;
    }
}

# Enable the configuration and acquire encrypted certificates
sudo ln -s /etc/nginx/sites-available/supabase /etc/nginx/sites-enabled/
sudo nginx -t && sudo systemctl reload nginx
sudo certbot --nginx -d supabase.yourdomain.com

Phase 6: Eradicating Bad Gateway Errors

Many developers complain about encountering sudden bad gateway errors after deploying their infrastructure. They mistakenly blame their web server configuration. The brutal reality is that this architecture requires immense hardware capabilities. When fifteen heavy containers compete for resources on a cheap shared virtual server the operating system runs out of memory.

The Linux kernel responds by silently assassinating the API gateway or database generating massive connection drops. Furthermore the Realtime subscription engine requires tremendous disk input output operations per second to broadcast database changes rapidly.