WZ-IT Logo
How-toSupabase

Install Supabase with Coolify and operate it in production

Timo WevelsiepTimo WevelsiepUpdated: 25.08.2026

Editorial note: Versions, commands and prices may change. Please verify critical steps independently before production use. This guide does not replace individual consulting.

Want to deploy Supabase through Coolify without improvising backups, updates and operations? WZ-IT provides managed Supabase hosting and migration plus managed Coolify hosting on dedicated or customer-controlled infrastructure.

To install Supabase with Coolify is an attractive entry into self-hosting. Coolify provides a management and deployment layer for containerised applications, domains and environment variables. Supabase combines PostgreSQL, Auth, Storage, Realtime, APIs, Functions, Studio and other services in one stack.

This simplifies deployment but does not remove engineering responsibility. Production needs both layers to work together: Coolify as the management platform and Supabase as a stateful backend.

What Coolify handles for Supabase

Depending on the deployment, Coolify can assist with:

  • provisioning containers and networks
  • managing domains and TLS
  • entering environment variables and secrets
  • viewing service state and logs
  • controlled recreation of containers
  • managing related frontends and backends

Coolify is not Supabase Cloud. It does not automatically deliver managed Supabase platform capabilities such as managed backups, PITR, branching or complete platform metrics.

What still requires an operating design

Area Remaining responsibility
PostgreSQL Backups, performance, extensions, connections and upgrades
Storage Capacity, object bytes, permissions and separate protection
Auth JWT, SMTP, providers, redirects and session behaviour
RLS Grants, policies, tenant isolation and negative tests
Functions Source, secrets, runtime, logs and deployment
Network Firewall, public endpoints, CORS and administration
Updates Template changes, image compatibility, testing and rollback
Recovery Restore database, files and configuration together

1. Capture workload and operating objectives

Before selecting a server, capture:

  • expected users and concurrent access
  • database size and growth
  • number and type of queries
  • Storage volume and transfer
  • Realtime connections
  • Functions and background work
  • other applications on the same Coolify
  • required RPO and RTO
  • acceptable maintenance and downtime

A hobby or test system differs from a SaaS product with customer data. Generic minimum sizes are starting points, not measurements.

2. Prepare the Coolify host

The host needs:

  • supported, maintained Linux
  • a restrictive firewall
  • SSH through limited keys or VPN
  • fast and monitored Storage
  • clean DNS records
  • a backup target outside the primary failure domain
  • monitoring for CPU, memory, disk, I/O and network

Coolify itself is privileged administration. Protect its interface, credentials and recovery. Losing the management plane must not also remove the only documentation and recovery path.

3. Review template and versions before deployment

Supabase self-hosting evolves. Platform templates can lag behind the upstream repository or contain their own adjustments. Before first start, compare:

  • source and freshness of the Coolify template
  • Supabase image versions
  • PostgreSQL version
  • required environment variables
  • volume and Storage paths
  • public and internal ports
  • the future update procedure

A known, current baseline is easier to operate than an unknown mix of movable image tags.

4. Design domains, TLS and endpoints

The application needs a stable Supabase URL. Internal and administrative endpoints need separate treatment.

Configure:

  • public API domain
  • TLS certificate and renewal
  • site URL and Auth redirects
  • OAuth callback URLs
  • allowed CORS origins
  • email links
  • Studio and administrative access
  • direct PostgreSQL or pooling connections

Do not expose Studio and database ports publicly without a reason. Administration can use VPN or a restricted network.

5. Secrets and Auth configuration

Use random, separate secrets before production. Depending on the stack these include:

  • PostgreSQL credentials
  • JWT and API keys
  • dashboard and Studio access
  • SMTP credentials
  • OAuth providers
  • Function secrets
  • external Storage or webhook credentials

Template example values must not remain. Do not copy secrets into screenshots, logs or a public repository. Establish rotation and recovery.

6. Test SMTP and Auth completely

Without correct SMTP, important flows become limited or unreliable:

  • registration and confirmation
  • magic links
  • password reset
  • invitations
  • email-address changes

Update domains and callback URLs for every OAuth provider. Test accounts cover login, logout, token refresh and failures.

7. Choose Storage deliberately

The database holds Supabase Storage metadata, not an independent copy of object bytes. Review:

  • local volume or compatible object target
  • expected capacity and growth
  • upload and download throughput
  • private and public buckets
  • Storage RLS
  • backup and recovery of actual objects

Local Storage on the same host shares its failure domain. External object Storage still needs access, lifecycle and backup rules.

8. Accept with real user journeys

After deployment, test more than green containers:

  1. registration and login
  2. password reset or magic link
  3. read and write API access
  4. RLS with two users or tenants
  5. file upload and private download
  6. Realtime connection
  7. Function call and error path
  8. SMTP, OAuth and webhook
  9. platform restart
  10. backup run and documented recovery exercise

9. Backups outside Coolify

Complete protection separately covers:

  • PostgreSQL
  • Storage object bytes
  • Coolify and Supabase configuration
  • schema migrations and Function source
  • image and version inventory
  • recovery procedures for secrets and domains

A server snapshot may complement this design, but does not automatically replace consistent, tested database and Storage backups. See back up Supabase completely.

10. Update under control

“Redeploy latest” is not a safe update process. Before a relevant update:

  • read official Supabase changes
  • compare the Coolify template and local state
  • verify backups
  • test in staging
  • accept Auth, RLS, Storage and Functions
  • define the window and rollback

See update self-hosted Supabase for the complete process.

When Supabase and Coolify should separate

Separation may make sense when:

  • PostgreSQL produces steady or high I/O
  • several apps compete for resources
  • maintenance windows differ
  • a management update must not affect the database
  • availability or recovery objectives increase
  • ownership is split

Use measurements and risk, not a universal rule, to choose the point.

Sources

Rather have it operated?

You'd rather not run Supabase yourself? WZ-IT handles setup, operations and maintenance - privacy-focused from Germany.

Enquiry

Migrate, secure, or operate Supabase

We migrate Supabase projects and existing backends such as Firebase, Lovable, PostgreSQL, MySQL or Auth0, build the target environment, and can take over ongoing operations.

How should we get back to you?

Frequently Asked Questions

Answers to the most important questions

Coolify can simplify container deployment considerably. A template does not replace review of secrets, domains, SMTP, Storage, RLS, backups, monitoring, versions and recovery.

There is no dependable number for every app. Coolify and the full Supabase stack need resources; database size, connections, Realtime, Functions and load drive sizing. Production systems are measured and retain headroom.

Yes for clearly bounded workloads. The management platform, database and apps then share resources and one failure domain. Criticality, growth, maintenance and recovery determine when separation is needed.

No. Coolify assists deployment and administration. PostgreSQL, Storage objects, Supabase compatibility, template changes, recovery tests and business smoke tests remain operating responsibilities.

Yes when host, access, versioning, backup, monitoring, updates and incident response are organised reliably. A successful initial deployment alone is not production operations.

Contact

Let's Talk About Your Idea

Whether a specific IT challenge or just an idea - we look forward to the exchange. In a brief conversation, we'll evaluate together if and how your project fits with WZ-IT.

Email
[email protected]
Arrange a callback

Callback

Arrange a callback

Leave your number and we will call back — at the latest on the next business day.

For a longer conversation you can book an appointment instead.

Companies worldwide trust WZ-IT

  • ml&s
  • Rekorder
  • Keymate
  • Führerscheinmacher
  • SolidProof
  • ARGE
  • Boese VA
  • nextGYM
  • Maho Management
  • Golem.de
  • Millenium
  • Paritel
  • Yonju
  • EVADXB
  • Mr. Clipart
  • Aphy AG
  • Negosh
  • ABCO Water Systems
1/3 - Topic Selection33%

What is your inquiry about?

First select the service area that best matches your project.