Supabase - Hardened Self-Hosted Postgres Backend

What is Supabase

Supabase is an open-source application backend built on PostgreSQL. It turns a Postgres database into a complete backend for web and mobile apps: instant RESTful and GraphQL APIs over your tables (PostgREST), a full authentication and user-management server (GoTrue), realtime subscriptions over WebSockets, S3-compatible object storage with image transformation, serverless edge functions, and the Supabase Studio dashboard. The self-hosted edition runs as a docker-compose deployment of eleven services - Studio, the Kong API gateway, Auth, REST, Realtime, Storage, imgproxy, postgres-meta, Edge Functions, the Postgres database, and the Supavisor connection pooler. Define tables and get APIs plus a typed client instantly, manage users, and subscribe to changes - without writing server code. Apache-2.0 license, no vendor lock-in.

Why self-host Supabase

Running Supabase on a VM you control keeps your database, user records, uploaded objects, and API keys inside your own tenant rather than a managed backend service - fitting data-residency requirements, GDPR/HIPAA/ISO 27001 programmes, and any product where the backend and its data must stay within your own perimeter with no per-request fees.

What this VM image adds

Security hardening:

• Every secret regenerated per instance at first boot - the Postgres password, the JWT signing secret, the dashboard password, the Realtime/Supavisor key base, the Vault and postgres-meta encryption keys, and the Storage S3 keys. The publicly known upstream demo values are never used.
• Both API keys (anon and service_role) freshly minted - re-signed JWTs from the per-instance JWT secret, so the public default keys that grant full database access are never shipped.
• Host nginx fronts the Kong API gateway on TCP 443 with a self-signed certificate (replaceable via the pre-installed certbot); HTTP redirects to HTTPS; the Studio dashboard is gated by HTTP Basic Auth.
• All eleven container images pinned by SHA-256 digest - reproducible builds, no surprise upgrades.
• Kong, Postgres (5432) and the Supavisor pooler (6543) bound to 127.0.0.1 only - nginx on 443 is the sole public-facing endpoint by default.
• UFW firewall - TCP 443 for buyer use, TCP 22 for SSH; all other inbound dropped.
• fail2ban SSH brute-force protection and AppArmor mandatory access control.
• CVE scan - every image is scanned with Trivy before release.

OS hardening (CIS Level 1):

• CIS Ubuntu 24.04 LTS Level 1 Benchmark via ansible-lockdown
• auditd for system call auditing; SSH hardening - key-only access, PermitRootLogin no, LoginGraceTime 60
• Kernel hardening - SYN cookies, ASLR, rp_filter, kexec disabled, IPv6 off; /tmp as tmpfs (nosuid, nodev, noexec)

Compliance artifacts (inside the VM):

• SBOM - CycloneDX 1.6 at /etc/lynxroute/sbom.json
• CIS Conformance Report at /etc/lynxroute/cis-report.html (OpenSCAP, Azure tailoring profile, 0 FAIL rules)
• Operator credentials file at /root/supabase-credentials.txt (mode 0600) with the dashboard login, both API keys, the Postgres password, and the project HTTPS URL

Quick Start

1. Deploy VM from Azure Marketplace (Standard_D2s_v3 recommended)
2. Open NSG: TCP 443 from your trusted sources only until you have logged in (the keys grant full API access); TCP 22 from your management IPs only
3. SSH: ssh -i key.pem azureuser@<PUBLIC_IP>, then sudo cat /root/supabase-credentials.txt for the dashboard and API credentials
4. Wait for first-boot initialization to finish - the stack takes a few minutes (database migrations plus eleven containers); a loading page is shown until the backend is ready, then switches to the dashboard automatically
5. Open https://<PUBLIC_IP>/ in your browser, accept the self-signed certificate warning, and log in to Studio with the Basic Auth credentials from the file

Use the API from your application: the project URL is https://<PUBLIC_IP> and the keys are in the credentials file. The Kong gateway routes /auth/v1, /rest/v1 and /graphql/v1, /realtime/v1, /storage/v1, and /functions/v1. Direct Postgres on 5432 (session) and 6543 (transaction pooler) is bound to localhost by default; open it explicitly for external connections. For production, replace the self-signed certificate with a CA-signed one, then set SUPABASE_PUBLIC_URL, API_EXTERNAL_URL and SITE_URL in /opt/supabase/.env and run sudo systemctl restart supabase.