Install Supabase with Coolify and operate it in production
Timo Wevelsiep•Updated: 25.08.2026Editorial 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:
- registration and login
- password reset or magic link
- read and write API access
- RLS with two users or tenants
- file upload and private download
- Realtime connection
- Function call and error path
- SMTP, OAuth and webhook
- platform restart
- 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.
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.
More on Supabase
- What is Supabase?
- Supabase Cloud vs self-hosted
- Supabase self-hosting: pros & cons
- Supabase cost: Cloud vs self-hosted
- Migrate Supabase Cloud to self-hosted
- Migrate a Supabase project, region or organisation
- Migrate PostgreSQL to Supabase
- Migrate AWS RDS and Aurora to Supabase
- Migrate Heroku Postgres to Supabase
- Migrate Neon and Vercel Postgres to Supabase
- Migrate MySQL and MariaDB to Supabase
- Migrate Microsoft SQL Server and Azure SQL to Supabase
- Migrate Firebase to Supabase
- Migrate Lovable Cloud to Supabase
- Migrate Auth0 to Supabase Auth
- Supabase migration checklist
- Back up Supabase completely
- Update self-hosted Supabase
- Audit Supabase RLS
- Run Supabase on Hetzner
- Install Supabase with Coolify





