Deploying Self-Hosted Supabase on Dokploy: A Complete Guide

Deploy self-hosted Supabase on Dokploy step by step: one-click template, secrets, domains, SSL, and the gotchas the template docs don't mention.

Cover Image for Deploying Self-Hosted Supabase on Dokploy: A Complete Guide

Dokploy has quietly become one of the most popular open-source PaaS options for self-hosters in 2026 — a lighter-weight alternative to Coolify with first-class Docker Compose support, a built-in Traefik reverse proxy, and automatic SSL. And since it ships an official Supabase template, it's now one of the fastest paths from a bare VPS to a running self-hosted Supabase stack.

Fast doesn't mean complete, though. The template gets containers running; it doesn't give you a production setup. This guide walks through deploying Supabase on Dokploy end to end — template deployment, secrets, domain configuration, and the post-deploy work (backups, service pruning, auth configuration) that actually determines whether your instance survives contact with real users. If you're still choosing where to run it, our server requirements docs and VPS provider comparison are the right starting points.

What Dokploy Is (and Where It Sits)

Dokploy is a self-hosted deployment platform: you install it on your own server, and it gives you a web UI for deploying applications from Git repos, Docker images, or Compose files. Think of it as the same category as Coolify — we covered that route in our Coolify deployment guide — but with a few differences that matter for Supabase specifically:

  • Native Docker Compose services. Supabase's self-hosted distribution is a Compose file with a dozen-plus containers. Dokploy treats Compose as a first-class citizen rather than an afterthought, which makes the Supabase stack less awkward to manage than on platforms built around single-container apps.
  • Traefik built in. Dokploy ships Traefik as its reverse proxy and handles Let's Encrypt certificates automatically. You won't hand-write proxy config to expose the API gateway and Studio.
  • Template auto-generates secrets. The official template generates POSTGRES_PASSWORD, JWT_SECRET, ANON_KEY, SERVICE_ROLE_KEY, and DASHBOARD_PASSWORD for you — which removes the single most common self-hosting failure mode: shipping with the demo JWT secret from the docs.

The honest trade-off: Dokploy manages deployments, not Supabase. It doesn't know what a Supabase project is. Logical backups of your database, storage file backups, auth provider configuration, multi-project orchestration — all of that remains your job after the containers go green.

Prerequisites

You'll need:

  • A VPS with at least 4 vCPUs, 4 GB RAM, and 50 GB of storage. The Supabase stack idles around 2–3 GB of RAM with all services enabled, and Dokploy itself needs headroom. 8 GB is the comfortable production floor — see our system requirements for per-service numbers.
  • Dokploy v0.22.5 or newer. The Supabase template requires it. Install with the one-liner from dokploy.com (curl -sSL https://dokploy.com/install.sh | sh).
  • A domain with an A record pointing at your server's IP. You'll want at least one subdomain for the API gateway and one for Studio.

One 2026-specific note before you start: as of June 2026, the self-hosted stack defaults to Postgres 17, and as of August 2026, Envoy replaced Kong as the default API gateway. Depending on when the template you deploy was last synced with upstream, you may get either gateway. Check which one you're running before you customize anything — if you have Kong-specific config to carry over, read our Kong-to-Envoy migration prep guide first.

Step 1: Deploy the Template

  1. In the Dokploy dashboard, create a Project (Dokploy's grouping unit — one per Supabase instance is sensible).
  2. Click Create Service → Template, search for Supabase, and click Create.
  3. Before deploying, open the Environment tab and review the generated values. Everything security-critical is pre-generated, but you should set these yourself:
# The public URL clients will hit (your API subdomain)
API_EXTERNAL_URL=https://api.yourdomain.com
SUPABASE_PUBLIC_URL=https://api.yourdomain.com

# Where auth emails link back to — your app, not Studio
SITE_URL=https://app.yourdomain.com

# Studio dashboard credentials (template generates the password; set the user)
DASHBOARD_USERNAME=admin
  1. Hit Deploy and wait. The first run takes several minutes — Postgres has to initialize, run its init scripts, and the dependent services (auth, rest, realtime, storage) restart until the database is ready. Containers cycling through unhealthy states during the first five minutes is normal; the same containers cycling after fifteen minutes is not.

A note on SITE_URL: getting it wrong is the top source of "auth emails link to localhost" bug reports. If signups redirect somewhere broken later, this is the first thing to check — our redirect URLs and Site URL guide covers the full resolution logic.

Step 2: Wire Up Domains and SSL

In the service's Domains tab, add two entries:

DomainContainerPort
api.yourdomain.comthe gateway (kong or envoy)8000
studio.yourdomain.comstudio3000

Enable HTTPS with the Let's Encrypt certificate option on both. Traefik handles issuance and renewal automatically — this is genuinely where Dokploy earns its keep versus hand-rolling Nginx, a process we documented in our reverse proxy setup guide if you want to understand what's happening underneath.

Two things the template won't do for you:

  • Studio is protected only by basic auth (DASHBOARD_USERNAME/DASHBOARD_PASSWORD). That's one shared credential standing between the internet and a UI with full database access. Either restrict Studio's domain to a VPN/allowlist, or skip exposing it publicly at all — see securing the Studio dashboard.
  • Port 5432 should not be public. The template doesn't expose it by default; resist the temptation to map it for convenience. Use a tunnel or Dokploy's terminal for direct database access.

Step 3: Trim Services You Don't Need

Since the June 2026 upstream change, analytics (Logflare) and the vector log shipper are opt-in rather than default — but template sync lags, so check what you're actually running. On a 4 GB server, analytics and vector can eat 1 GB+ for features most projects never open. If you don't need imgproxy (image transformations) or realtime either, comment them out of the Compose file in Dokploy's editor and redeploy.

This is worth doing deliberately rather than reflexively — some services have non-obvious dependents. Our selective service deployment guide maps which containers depend on which.

Step 4: The Part the Template Doesn't Cover

Here's the honest assessment of where a fresh Dokploy-deployed Supabase stands:

Backups. Dokploy has a backup feature for its own managed databases — but the Supabase Postgres container isn't one of them, so it's not covered. You need pg_dump on a schedule shipping somewhere off-server, plus a copy of the storage volume (file uploads live on disk, not in Postgres — the forgotten piece of most backup setups). This is exactly the gap Supascale exists for: scheduled S3 backups covering both database and storage, with one-click restore, configured in minutes — see creating backups.

Auth providers. OAuth setup means editing GoTrue environment variables by hand in the Compose editor and redeploying for every change. Workable, tedious, easy to typo. Supascale gives you a configuration UI for Google, GitHub, Discord and others instead.

The October 30 deadline. If you're deploying a project that existed before October 2026, be aware that tables in public stop being auto-exposed to the Data API at the end of this month — new deployments via current images already use explicit grants, but data you migrate in may not.

Supascale's license is one-time, from $99 for unlimited projects — the pricing page has the breakdown — and it runs alongside Dokploy fine: Dokploy owns the deployment, Supascale owns the Supabase-specific operations.

Dokploy vs. Coolify for Supabase: Quick Verdict

Both work. Dokploy's Compose handling is a bit cleaner and its UI is snappier; Coolify has a larger community and more battle-tested edge-case documentation. If you're already invested in one, there's no compelling reason to switch for Supabase's sake. If you're starting fresh on a single server with a Compose-heavy stack, Dokploy is the slightly more natural fit.

Either way, the platform solves deployment — not operations. Budget your attention accordingly: the deploy takes an afternoon; backups, auth, monitoring and upgrades are the recurring work.

Further Reading