Self-Hosting Supabase on Linux VPS in Pakistan: Production PostgreSQL, Auth, Realtime & S3 Architecture

For Pakistani software agencies, mobile dev shops, and venture-backed SaaS startups, managed backend-as-a-service (BaaS) platforms like Firebase and Supabase Cloud present a painful double-edged sword. While their developer ergonomics—instant REST/GraphQL APIs, real-time WebSockets, managed authentication, and row-level security (RLS)—accelerate time-to-market, their operational economics in Pakistan have become unsustainable.

Between aggressive USD-denominated pricing tiers, 10–15% foreign payment withholding taxes levied by local commercial banks, strict corporate debit/credit card international transaction limits, and high round-trip network latency (often 160ms–220ms when routing traffic to eu-central-1 or us-east-1), relying on overseas cloud BaaS places an unnecessary tax on your business margins and user experience.

The solution is deploying a production-grade, self-hosted Supabase stack on high-performance Linux VPS infrastructure.

By self-hosting Supabase on a localized Linux VPS or enterprise Dedicated Servers in Pakistan, development teams achieve:

• Sub-25ms database query round-trips across Karachi, Lahore, and Islamabad.
• Zero USD billing surprises, predictable fixed rupee operating costs, and evasion of cross-border card declines.
• Complete data sovereignty adhering to State Bank of Pakistan (SBP) and SECP cloud compliance mandates for fintech and healthtech applications.
• Unrestricted hardware compute, enabling custom AI vector embeddings (pgvector), unmetered real-time WebSocket concurrency, and custom background workers without per-row or per-function execution penalties.

This comprehensive guide details the exact architecture, configuration files, kernel optimizations, and operational runbooks required to deploy, tune, and maintain a high-availability, self-hosted Supabase cluster in production.

---

Supabase Microservices Architecture Overview

Supabase is not a monolithic application; it is an orchestrated federation of high-performance open-source microservices centered around PostgreSQL:

                          [ Client Applications (Web / Mobile) ]
                                            │
                                            ▼
                      [ TLS Reverse Proxy (Caddy / Nginx) :443 ]
                                            │
                                            ▼
                           [ Kong API Gateway :8000 ]
             ┌──────────────┬───────────────┼──────────────┬─────────────┐
             ▼              ▼               ▼              ▼             ▼
       [ PostgREST ]   [ GoTrue Auth ]  [ Realtime ]  [ Storage-API ] [ Functions ]
         (:3000)          (:9999)         (:4000)         (:5000)       (:8081)
             │              │               │              │             │
             └──────────────┼───────────────┴──────────────┘             │
                            ▼                                            │
               [ Supavisor / pgBouncer Pooler ]                          │
                            │                                            │
                            ▼                                            ▼
           [ PostgreSQL 15/16 + pgvector ]                      [ MinIO / S3 Bucket ]

1. Kong Gateway (:8000): Acts as the unified public API gateway, routing subpaths (/rest/v1, /auth/v1, /realtime/v1, /storage/v1, /functions/v1) to upstream microservices and enforcing API key / JWT headers.
2. PostgreSQL 15/16 (:5432): The single source of truth, housing client tables, schemas, auth state, Row Level Security (RLS) policies, and vector embeddings (pgvector).
3. PostgREST (:3000): Standalone web server that introspects your Postgres schema and translates RESTful HTTP calls directly into executed SQL statements.
4. GoTrue (:9999): Authentication server handling password hashing, JWT minting, OAuth2 providers, magic links, and MFA tokens.
5. Realtime (:4000): Elixir-based cluster listening to PostgreSQL logical replication streams via pgoutput and broadcasting change events over WebSockets.
6. Storage API (:5000): S3-compatible file storage middleware orchestrating uploads, thumbnails, and access policies against local MinIO or remote S3 buckets.
7. Supavisor / pgBouncer: Multi-tenant connection poolers preventing database connection exhaustion during high-concurrency mobile bursts.
8. Studio (:3000 / :8000): The developer web UI for database inspection, SQL queries, table editors, and policy management.

---

Sizing Your VPS Infrastructure

Running Supabase requires allocating resources across both memory-intensive microservices (Realtime Elixir BEAM VM and JVM/Deno runtimes) and write-optimized disk I/O for PostgreSQL.

Workload Tier	Concurrent Users	Recommended Spec	Target Workload
Starter / MVP	500 – 5,000	4 vCPU, 8 GB RAM, 80 GB NVMe	Internal dashboards, early-stage mobile apps, MVPs
Production Agency	5,000 – 50,000	8 vCPU, 16–32 GB RAM, 200 GB NVMe	Multi-app backend, high-volume e-commerce, real-time fleet tracking
High-Throughput Enterprise	50,000+	16–32 vCPU, 64–128 GB ECC RAM, NVMe RAID	Core banking APIs, high-frequency vector embeddings, national delivery platforms

[!TIP] For agencies running 10+ multi-tenant client backends or AI embedding models on a single infrastructure footprint, deploying bare-metal Dedicated Servers provides dedicated L3 CPU cache, unthrottled NVMe disk IOPS, and complete isolation from virtualized hypervisor noisy neighbors.

---

Step 1: Base Linux OS Preparation & Docker Setup

Deploy an Ubuntu 24.04 LTS or Debian 12 64-bit instance. Connect via SSH and initialize system security and kernel parameters.

1.1 System Updates and Essential Dependencies

sudo apt update && sudo apt upgrade -y
sudo apt install -y curl wget git jq ufw htop net-tools fail2ban ca-certificates gnupg lsb-release

1.2 Kernel & Network Tuning for Realtime WebSockets

Supabase Realtime maintains thousands of persistent WebSocket connections. Modify /etc/sysctl.d/99-supabase.conf to expand Linux socket limits:

# /etc/sysctl.d/99-supabase.conf
# Increase max open file descriptors and socket backlog
fs.file-max = 2097152
net.core.somaxconn = 65535
net.ipv4.tcp_max_syn_backlog = 65535

# Fast socket reuse
net.ipv4.tcp_tw_reuse = 1
net.ipv4.tcp_fin_timeout = 15

# Memory limits for high-volume network buffering
net.core.rmem_max = 16777216
net.core.wmem_max = 16777216
net.ipv4.tcp_rmem = 4096 87380 16777216
net.ipv4.tcp_wmem = 4096 65536 16777216

# Virtual memory paging for PostgreSQL
vm.swappiness = 10
vm.dirty_background_ratio = 5
vm.dirty_ratio = 10

Apply the parameters:

sudo sysctl --system

1.3 Install Docker Engine & Compose Plugin

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

echo \
  "deb [arch=$(dpkg --print-architecture) signed-by=/etc/apt/keyrings/docker.gpg] https://download.docker.com/linux/ubuntu \
  $(lsb_release -cs) stable" | sudo tee /etc/apt/sources.list.d/docker.list > /dev/null

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

# Enable and start Docker service
sudo systemctl enable --now docker

---

Step 2: Supabase Deployment & Environment Hardening

Clone the official Supabase repository repository to extract the production Docker Compose setup:

cd /opt
sudo git clone --depth 1 https://github.com/supabase/supabase
sudo mv supabase/docker /opt/supabase-docker
sudo rm -rf /opt/supabase
cd /opt/supabase-docker

2.1 Generating Cryptographic Keys

Never use the default keys provided in the demo .env.example. Generate unique, high-entropy secrets:

# Generate high-entropy database password
POSTGRES_PASS=$(openssl rand -hex 24)

# Generate JWT Secret (minimum 32 characters)
JWT_SECRET=$(openssl rand -hex 32)

# Generate Secret Keys for MinIO S3 storage
MINIO_ROOT_USER="s3admin_$(openssl rand -hex 4)"
MINIO_ROOT_PASSWORD=$(openssl rand -hex 24)

echo "Postgres Password: $POSTGRES_PASS"
echo "JWT Secret: $JWT_SECRET"

Next, use an online tool or the Node.js/Python script below to generate valid Supabase ANON_KEY and SERVICE_ROLE_KEY tokens signed with your new JWT_SECRET:

# generate_tokens.py
import jwt
import time

jwt_secret = "YOUR_GENERATED_JWT_SECRET"
now = int(time.time())
exp = now + (10 * 365 * 24 * 60 * 60) # 10 years

anon_payload = {
    "role": "anon",
    "iss": "supabase",
    "iat": now,
    "exp": exp
}

service_payload = {
    "role": "service_role",
    "iss": "supabase",
    "iat": now,
    "exp": exp
}

anon_key = jwt.encode(anon_payload, jwt_secret, algorithm="HS256")
service_key = jwt.encode(service_payload, jwt_secret, algorithm="HS256")

print(f"ANON_KEY: {anon_key}")
print(f"SERVICE_ROLE_KEY: {service_key}")

2.2 Configuring .env for Production

Copy .env.example to .env and configure production variables:

sudo cp .env.example .env
sudo nano .env

Apply these critical configuration updates:

# Studio Configuration
STUDIO_PORT=3000
SITE_URL=https://api.yourdomain.pk
SUPABASE_PUBLIC_URL=https://api.yourdomain.pk

# Database Secrets
POSTGRES_PASSWORD=YourGeneratedPostgresPassword
POSTGRES_PORT=5432
POSTGRES_DB=postgres

# API Gateway & Security
JWT_SECRET=YourGenerated32ByteHexSecret
ANON_KEY=YourGeneratedAnonJwt
SERVICE_ROLE_KEY=YourGeneratedServiceJwt

# GoTrue / Auth Settings
API_EXTERNAL_URL=https://api.yourdomain.pk
GOTRUE_SITE_URL=https://yourfrontend.pk
GOTRUE_URI_ALLOW_LIST=https://yourfrontend.pk/*,https://app.yourfrontend.pk/*
GOTRUE_JWT_EXP=3600
GOTRUE_JWT_SECRET=YourGenerated32ByteHexSecret

# External SMTP Configuration (Transactional Email)
GOTRUE_SMTP_HOST=smtp.postmarkapp.com
GOTRUE_SMTP_PORT=587
GOTRUE_SMTP_USER=your-postmark-token
GOTRUE_SMTP_PASS=your-postmark-token
GOTRUE_SMTP_ADMIN_EMAIL[email protected]
GOTRUE_MAILER_AUTOCONFIRM=false

# Realtime WebSocket Configuration
PORT=4000
SECRET_KEY_BASE=GenerateA64ByteRandomHexSecret
DB_HOST=db
DB_PORT=5432
DB_NAME=postgres
DB_USER=supabase_admin
DB_PASSWORD=YourGeneratedPostgresPassword
REPLICATION_MODE=RLS

# Storage Configuration (Local MinIO or S3)
STORAGE_BACKEND=file
GLOBAL_S3_BUCKET=supabase-storage
FILE_STORAGE_BACKEND_PATH=/var/lib/storage
TENANT_ID=stub

---

Step 3: PostgreSQL Optimization & pgvector

Supabase leverages PostgreSQL for both relational storage and AI vector embeddings. Default Docker configs use conservative memory defaults meant for development laptops.

3.1 Tuning postgresql.conf for Production VPS

Create or update /opt/supabase-docker/volumes/db/custom-postgresql.conf (assuming an 8 vCPU / 16 GB RAM VPS tier):

# Custom PostgreSQL Tuning for 16GB RAM VPS
max_connections = 250
shared_buffers = 4GB                  # 25% of total RAM
effective_cache_size = 12GB           # 75% of total RAM
maintenance_work_mem = 1GB
work_mem = 16MB                       # Prevents OOM during concurrent joins
min_wal_size = 1GB
max_wal_size = 16GB
checkpoint_completion_target = 0.9
checkpoint_timeout = 15min
wal_buffers = 16MB
default_statistics_target = 100

# NVMe Storage Optimizations
random_page_cost = 1.1                # Fast NVMe flash read cost
effective_io_concurrency = 200

# Parallel Query Tuning
max_worker_processes = 8
max_parallel_workers_per_gather = 4
max_parallel_workers = 8
max_parallel_maintenance_workers = 4

# Logical Replication for Realtime Engine
wal_level = logical
max_replication_slots = 10
max_wal_senders = 10

Mount this file inside docker-compose.yml under the db service definition:

services:
  db:
    image: supabase/postgres:15.6.1.139
    command:
      - postgres
      - -c
      - config_file=/etc/postgresql/custom-postgresql.conf
    volumes:
      - ./volumes/db/custom-postgresql.conf:/etc/postgresql/custom-postgresql.conf:ro
      - ./volumes/db/data:/var/lib/postgresql/data

3.2 Enabling pgvector for On-Prem AI / RAG Applications

Supabase comes pre-loaded with pgvector in its database image. Verify and enable it by accessing the database console:

-- Connect via psql
CREATE EXTENSION IF NOT EXISTS vector;

-- Example: High-speed HNSW index for OpenAI / Gemini 1536-dimensional embeddings
CREATE TABLE document_embeddings (
    id bigserial PRIMARY KEY,
    document_id uuid NOT NULL,
    content text NOT NULL,
    embedding vector(1536)
);

-- Build hierarchical navigable small world (HNSW) index for sub-5ms cosine search
CREATE INDEX ON document_embeddings 
USING hnsw (embedding vector_cosine_ops)
WITH (m = 16, ef_construction = 64);

---

Step 4: Reverse Proxy & Production SSL Termination (Caddy)

While Kong handles internal routing between microservices on port 8000, public traffic should be terminated via Caddy or Nginx for automatic TLS certificates and WebSocket upgrades.

Caddy is the ideal zero-maintenance reverse proxy because it handles Let’s Encrypt / ZeroSSL renewal completely automatically.

4.1 Install and Configure Caddy

sudo apt install -y debian-keyring debian-archive-keyring apt-transport-https
curl -1sLf 'https://dl.cloudsmith.io/public/caddy/stable/gpg.key' | sudo gpg --dearmor -o /usr/share/keyrings/caddy-stable-archive-keyring.gpg
curl -1sLf 'https://dl.cloudsmith.io/public/caddy/stable/debian.deb.txt' | sudo tee /etc/apt/sources.list.d/caddy-stable.list
sudo apt update && sudo apt install -y caddy

4.2 Configure /etc/caddy/Caddyfile

# Public Supabase API Gateway
api.yourdomain.pk {
    encode zstd gzip

    # Proxy to Kong API Gateway (Port 8000)
    reverse_proxy 127.0.0.1:8000 {
        header_up Host {host}
        header_up X-Real-IP {remote_host}
        header_up X-Forwarded-For {remote_host}
        header_up X-Forwarded-Proto {scheme}

        # Crucial for Realtime WebSocket streaming
        transport http {
            keepalive 120s
            compression off
        }
    }
}

# Supabase Studio Dashboard (Protected via IP or Basic Auth)
studio.yourdomain.pk {
    encode zstd gzip

    # Restrict admin studio access to office / VPN IPs
    @allowed remote_ip 111.119.160.0/20 127.0.0.1
    handle @allowed {
        reverse_proxy 127.0.0.1:3000
    }

    # Deny all unauthorized IPs
    handle {
        respond "Access Denied" 403
    }
}

Reload Caddy to initiate SSL handshakes:

sudo systemctl restart caddy

---

Step 5: Production Firewall & Security Hardening

Never expose PostgreSQL (5432), PostgREST (3000), or Kong (8000) directly to the public internet. Only HTTP (80) and HTTPS (443) should be open publicly, alongside your hardened SSH port.

# Set baseline defaults
sudo ufw default deny incoming
sudo ufw default allow outgoing

# Allow SSH (recommended on non-standard port)
sudo ufw allow 22/tcp

# Allow Web Traffic for Caddy
sudo ufw allow 80/tcp
sudo ufw allow 443/tcp

# Enable Firewall
sudo ufw enable

Inside your docker-compose.yml, ensure the port binds for kong, db, and studio are bound strictly to 127.0.0.1 rather than 0.0.0.0:

ports:
  - "127.0.0.1:8000:8000"   # Kong
  - "127.0.0.1:3000:3000"   # Studio
  - "127.0.0.1:5432:5432"   # PostgreSQL (Local only)

---

Step 6: Automated Encrypted Backup Strategy

A production database without an automated, offsite, point-in-time recovery (PITR) backup pipeline is an accident waiting to happen.

We implement an automated backup pipeline using pg_dump, AES-256 GPG encryption, and rclone to sync dumps to an offsite S3 or Cloudflare R2 bucket nightly.

6.1 Create the Backup Script

Create /opt/scripts/backup-supabase.sh:

#!/usr/bin/env bash
set -eo pipefail

TIMESTAMP=$(date +"%Y%m%d_%H%M%S")
BACKUP_DIR="/var/backups/supabase"
FILENAME="supabase_db_${TIMESTAMP}.sql.gz"
ENCRYPTED_FILE="${FILENAME}.gpg"
GPG_PASSPHRASE="YourSecureBackupEncryptionSecret"

mkdir -p "${BACKUP_DIR}"

echo "[*] Starting PostgreSQL dump..."
docker exec -t supabase-db pg_dump -U postgres -d postgres | gzip -9 > "${BACKUP_DIR}/${FILENAME}"

echo "[*] Encrypting archive with AES-256..."
gpg --batch --yes --passphrase "${GPG_PASSPHRASE}" --symmetric --cipher-algo AES256 -o "${BACKUP_DIR}/${ENCRYPTED_FILE}" "${BACKUP_DIR}/${FILENAME}"
rm "${BACKUP_DIR}/${FILENAME}"

echo "[*] Syncing offsite via Rclone..."
rclone copy "${BACKUP_DIR}/${ENCRYPTED_FILE}" remote-backup:supabase-backups/daily/

echo "[*] Cleaning local backups older than 7 days..."
find "${BACKUP_DIR}" -type f -name "*.gpg" -mtime +7 -delete

echo "[] Backup completed successfully at $(date)"

Make it executable and register a cron job:

sudo chmod +x /opt/scripts/backup-supabase.sh
sudo crontab -e

Add the nightly execution at 2:30 AM PKT:

30 2 * * * /opt/scripts/backup-supabase.sh >> /var/log/supabase-backup.log 2>&1

---

Comparative Analysis: Self-Hosted VPS vs. Supabase Cloud

Feature / Metric	Managed Supabase Cloud	Self-Hosted on Nextgen Linux VPS
Monthly Pricing Model	USD $25/mo base + compute add-ons + data transfer	Fixed PKR invoice starting at Rs. 4,500/mo
Pakistani Bank Card Friction	Frequent declines, 10–15% foreign exchange withholding taxes	100% local invoicing via Raast, JazzCash, or local IBFT
Network Latency (PK Users)	180ms – 240ms (EU/US edge regions)	15ms – 28ms (local datacenter routing)
Database Concurrency	Restricted by pooled worker quotas	Tuned directly via postgresql.conf & Supavisor
Realtime WebSocket Quotas	Metered concurrent connections	Uncapped (bound only by physical RAM & CPU)
AI Vector Embeddings	Limited memory tiers for pgvector indexes	Up to 128 GB dedicated ECC RAM on Dedicated Servers
Regulatory Compliance	International multi-tenant cloud storage	100% localized data sovereignty complying with SBP/SECP

---

Launch Your Production Supabase Node Today

Escaping prohibitive dollar inflation, slow latency round-trips, and arbitrary BaaS compute limits is the single most impactful infrastructure upgrade a Pakistani software agency can make in 2026.

By running Supabase over modern, locally peered Linux VPS instances, you retain the complete developer velocity of modern backend frameworks while maintaining absolute control over your database schemas, privacy, and operating margins.

---