Deploying Self-Hosted Supabase on Coolify: A Complete Guide

Coolify has become one of the most popular ways to get self-hosted Supabase running. It gives you a one-click service template, automatic Traefik reverse proxy wiring, and a dashboard for managing environment variables—a big step up from hand-editing docker-compose.yml over SSH. But "one-click" is doing a lot of work in that sentence. The Supabase stack is the most complex service template Coolify ships, and there are configuration decisions you must get right before your first deploy, because changing them later means database surgery.

This guide walks through deploying Supabase on Coolify properly: what to configure up front, the pitfalls the community keeps hitting, and—honestly—what Coolify does and doesn't solve compared to a purpose-built tool like Supascale. If you'd rather skip the manual configuration entirely, our installation guide covers the managed path.

Why Coolify for Supabase?

Coolify is an open-source, self-hostable PaaS—think Heroku you run on your own VPS. For Supabase specifically, it offers:

A maintained service template. Coolify bundles the full Supabase stack (Postgres, GoTrue, PostgREST, Realtime, Storage, Kong, Studio) as a docker-compose template, so you don't assemble it yourself.
Reverse proxy out of the box. Traefik handles routing and Let's Encrypt certificates, which removes one of the fiddlier parts of a manual setup (we covered the manual approach in our reverse proxy guide).
Secret generation. Coolify generates the JWT secret, anon key, and service role key for you on first setup.
A UI for environment variables. No more nano .env over SSH.

That's genuinely useful. The Hetzner community even maintains an official tutorial for the Coolify + Supabase combo, which tells you how mainstream this path has become.

Prerequisites

Before you start, you need:

A VPS with at least 4 GB RAM and 2 vCPUs. Coolify itself wants ~2 GB, and the full Supabase stack adds another 2–3 GB at idle. An 8 GB machine is the comfortable choice—see our system requirements and our breakdown of the best VPS providers for self-hosted Supabase.
A domain with DNS you control, pointed at the server (an A record for the API and one for Studio).
SSH access as root for the Coolify installer.

Step 1: Install Coolify

curl -fsSL https://cdn.coollabs.io/coolify/install.sh | bash

The installer sets up Docker, the Coolify dashboard, and Traefik. Once it finishes, open http://<your-server-ip>:8000, create your admin account, and configure your instance domain so the dashboard itself gets SSL.

Step 2: Create the Supabase Service

In the Coolify dashboard:

Create a new Project, then add a Resource.
Choose Service → search for Supabase.
Coolify generates the full compose stack with randomized secrets.

Stop here. Do not click Deploy yet. The next step is where most failed deployments are born.

Step 3: Configure Before First Deploy

A few settings are effectively immutable after the first boot:

Set the pooler tenant ID

Supavisor (the connection pooler) uses POOLER_TENANT_ID as part of its database username scheme (postgres.<tenant-id>). Per the Coolify docs, changing it after initial deployment requires manual database migrations inside the pooler's metadata. Set it to something meaningful (e.g., your project name) now.

Review the generated secrets

Coolify generates JWT_SECRET, ANON_KEY, and SERVICE_ROLE_KEY for you. Verify the anon and service role keys were actually signed with the JWT secret—older Coolify versions occasionally produced mismatches, which surfaces later as JWT verification failed errors on every API call. If you need to regenerate them, do it before clients exist.

Configure SMTP

GoTrue (Supabase Auth) won't send signup confirmations or password resets without SMTP settings. Set SMTP_HOST, SMTP_PORT, SMTP_USER, SMTP_PASS, and SMTP_ADMIN_EMAIL before deploying, or set ENABLE_EMAIL_AUTOCONFIRM=true temporarily while testing. Our environment variables guide explains the full matrix.

Set your domains

Assign your API domain (e.g., api.example.com) to the Kong service and a separate domain for Studio. Traefik will provision certificates automatically once DNS resolves.

Step 4: Deploy and Verify

Click Deploy and watch the logs. First boot takes a few minutes while Postgres initializes and the analytics service (Logflare) becomes healthy—other services wait on it, so a stuck supabase-analytics container is the most common cause of an endlessly "starting" stack.

Verify with:

curl https://api.example.com/rest/v1/ \
  -H "apikey: <your-anon-key>"

A JSON response (even an empty schema listing) means Kong, PostgREST, and your JWT keys all agree.

Common Pitfalls

These come up constantly in r/selfhosted and the Coolify Discord:

Exposing Postgres publicly is buggy. Coolify's "make publicly accessible" toggle has a known issue with the Supabase template. The documented workaround is editing the compose to publish port 5432 on the pooler (or Postgres directly) and opening the firewall yourself. If you do, restrict the port to known IPs—an open 5432 gets credential-stuffed within hours. Our network security guide covers locking this down.

Studio ships with shared basic auth. The template protects Supabase Studio with a single username/password pair—no users, no MFA, no audit trail. Treat that as a placeholder, not security. We wrote up better options in securing the Studio dashboard.

Upgrades are on you. Coolify deploys a snapshot of the Supabase compose template. When Supabase ships new image versions (or breaking changes, like the October 2026 Data API grants change), Coolify won't upgrade your stack automatically—you bump image tags yourself and hope the migration order is right.

WebSockets need care. Realtime subscriptions fail silently if the proxy doesn't forward upgrade headers. Traefik usually handles this, but if you put Cloudflare in front, check your WebSocket settings.

What Coolify Doesn't Solve

Here's the honest part. Coolify is a deployment tool, and it's good at that. But running Supabase in production is mostly what happens after deployment:

Backups. Coolify's scheduled backups target its own managed databases. The Postgres inside the Supabase service template isn't covered the same way—and Storage files (avatars, uploads) aren't backed up at all. You're back to cron jobs and pg_dump scripts, the exact problem we dug into in the self-hosted backup and restore guide.
Restores. Even with backups in place, restoring means manual psql sessions and praying the dump's role grants match a fresh stack.
OAuth configuration. Adding Google or GitHub login means hand-editing a dozen GOTRUE_EXTERNAL_* env vars and redeploying. There's no UI for it.
Multi-project management. One Supabase service per Coolify project works, but each one repeats all of the above—secrets, SMTP, backups, upgrades.

Supascale was built for exactly this gap. It deploys Supabase too, but then keeps managing it: automated S3 backups with one-click restore that include Storage files, a UI for OAuth provider configuration, custom domains with automatic SSL, and selective service deployment so you only run the containers you need. It's a one-time $39.99 purchase for unlimited projects—no subscription—which you can compare on the pricing page.

Can you run both? Sure—plenty of people keep app deployments on Coolify and let Supascale own the Supabase layer. They're different tools for different jobs.

Conclusion

Coolify is a legitimate, well-trodden path to self-hosted Supabase: install, configure the tenant ID and SMTP before first deploy, assign domains, and verify your JWT keys match. Just go in with clear eyes about what it covers. Deployment is day one; backups, restores, OAuth, and upgrades are every day after that.

If you want the deployment and the day-two operations handled, try Supascale—it takes about 10 minutes to go from a bare VPS to a fully managed Supabase instance with backups already scheduled.