Deploy Supabase with the supabase-selfhost template

Stand up the full self-hosted Supabase backend on a single Quake AI instance using the validated OpenTofu template supabase-selfhost. You apply the template, read the generated credentials, point a domain at the host and serve it over HTTPS, set the public URL, sign in to Studio, create a table, and query it through the REST API.

Supabase keeps your application's database, auth, storage, and realtime layer on infrastructure you own. You run it yourself; this is a self-hosted backend you operate, not the managed Supabase cloud.

Prerequisites#

You need:

• OpenTofu 1.6.0 or later (or Terraform 1.6.0 or later) installed locally.
• Your OpenStack credentials sourced into the shell (source openrc.sh). See the OpenStack CLI guide.
• An SSH keypair that already exists in your project. Record its name for the key_name variable.
• A copy of the supabase-selfhost template directory from the template reference page.
• A domain you can point at the instance. Supabase Auth builds callback URLs from a stable public URL.

Step 1: Apply the template#

Copy the template's example variables file and set key_name:

cp terraform.tfvars.example terraform.tfvars

key_name = "YOUR_KEY_NAME"

Initialize, preview, and apply:

tofu init
tofu plan
tofu apply

OpenTofu provisions a private network, a router, a security group, a block volume mounted at /opt/supabase, an instance, and a floating IP. On first boot, cloud-init installs Docker Engine, clones the Supabase stack, generates every secret into /opt/supabase/.env, and runs docker compose up -d.

Read the outputs and record floating_ip, api_url, and studio_url:

tofu output

Step 2: Read the generated credentials#

Every secret was generated on the instance. SSH in and read them once:

ssh ubuntu@YOUR_FLOATING_IP
sudo cat /opt/supabase/.env

Record ANON_KEY, SERVICE_ROLE_KEY, DASHBOARD_USERNAME, and DASHBOARD_PASSWORD, and store them in your secret manager. The anon key is safe to ship in client code; the service_role key bypasses row-level security and stays server-side only.

The stack takes a few minutes to pull and start on first boot. Confirm the containers are healthy:

cd /opt/supabase
sudo docker compose ps

Step 3: Point a domain at the host and serve HTTPS with Caddy#

Supabase Auth builds absolute callback links from its public URL, so it needs a domain with TLS before it serves production traffic.

1. Create a DNS A record for your domain (for example api.example.com) pointing at YOUR_FLOATING_IP. Follow How to point a domain at a Quake AI resource. Wait until it resolves:

dig +short api.example.com

1. On the instance, create /opt/supabase/Caddyfile:

api.example.com {
  reverse_proxy 127.0.0.1:8000
}

1. Add Caddy to /opt/supabase/docker-compose.yml:

services:
  caddy:
    image: caddy:2
    restart: unless-stopped
    network_mode: host
    volumes:
      - /opt/supabase/Caddyfile:/etc/caddy/Caddyfile
      - caddy_data:/data
volumes:
  caddy_data:

For background on certificates, see How to issue and auto-renew a TLS certificate with Let's Encrypt.

Step 4: Set the public URL and restart#

Edit /opt/supabase/.env and set the three URL variables to your HTTPS address:

API_EXTERNAL_URL=https://api.example.com
SUPABASE_PUBLIC_URL=https://api.example.com
SITE_URL=https://api.example.com

Restart the stack so the services pick up the new URLs:

cd /opt/supabase
sudo docker compose up -d

Step 5: Sign in to Studio and create a table#

1. Open Studio. Over the reverse proxy, route a second hostname (for example studio.example.com) to port 3000, or tunnel to it over SSH for setup: ssh -L 3000:localhost:3000 ubuntu@YOUR_FLOATING_IP and open http://localhost:3000.
2. Sign in with DASHBOARD_USERNAME and DASHBOARD_PASSWORD from /opt/supabase/.env.
3. Open the Table Editor, create a table named notes with a text column called body, and insert a row.

Step 6: Query the REST API#

Supabase generates a REST endpoint for every table. Query notes through the API gateway with your anon key:

curl "https://api.example.com/rest/v1/notes?select=*" \
  -H "apikey: YOUR_ANON_KEY" \
  -H "Authorization: Bearer YOUR_ANON_KEY"

The row you inserted in Studio comes back as JSON. Point a Supabase client library at https://api.example.com with the anon key to build against the same API from your application.

What you built#

• Applied the supabase-selfhost template to provision a network, security group, data volume, instance, and floating IP, with the full Supabase stack started by cloud-init
• Read the generated credentials from /opt/supabase/.env
• Served the stack over HTTPS by pointing a domain at the floating IP and routing it through a Caddy reverse proxy
• Set the public URL so Auth callbacks resolve
• Created a table in Studio and queried it through the auto-generated REST API

Scope of this deployment#

This template runs a single-VM Supabase host, not the managed Supabase cloud. The instance is CPU-only and runs in one region, and it runs every Supabase service as a container on one host. You operate the instance, Docker, Postgres, and the data volume yourself: back them up, patch them, and snapshot the volume before you resize or rebuild. For high availability, move Postgres onto its own instance and run the stateless services behind a load balancer.

Next steps#

• Supabase self-host template: the template reference, parameters, and resource map
• Self-managed PostgreSQL template: the database to point at when you outgrow the bundled one
• How to store application secrets and inject them at runtime: manage the API keys and database password
• Security hardening checklist: tighten SSH access and exposure before you serve real traffic

Clean up#

When you no longer need the deployment, destroy everything the template created:

tofu destroy

Then remove the DNS A records you created in step 3. Because Postgres, storage uploads, and the analytics data all live on the instance and its attached volume, tofu destroy removes them along with the infrastructure. Export any data you want to keep first with pg_dump against the database.