Want Supabase on Hetzner or a Cloud migration without building an operations team? WZ-IT provides managed Supabase hosting, migration and operations on dedicated or customer-controlled infrastructure.
It is technically straightforward to run Supabase on Hetzner: the self-hosted stack is container-based, while Hetzner provides Cloud servers, dedicated servers, networks and storage components. The architecture decision begins after the first successful start.
A production platform needs database, Auth, Storage, Realtime, Functions, networking, backup, monitoring and updates to be designed as one system.
When Hetzner is a useful Supabase target
Common reasons include:
- a controllable operating location in Europe
- dedicated or customer-controlled infrastructure
- private connections to other systems
- predictable resources for PostgreSQL
- migration from Supabase Cloud or a prototype
- integration into an existing Hetzner or WZ-IT environment
- a clear managed-operations model
Location alone creates neither security nor sovereignty. Control comes from documented access, portability, backups, recovery and named ownership.
Cloud server or dedicated server
| Criterion | Hetzner Cloud | Dedicated server |
|---|---|---|
| Provisioning | Fast and API-driven | Hardware provisioning |
| Resources | Virtualised and flexible | Exclusive and predictable |
| Adjustment | Easy resizing and automation | More hardware and Storage options |
| Entry | Strong for development and smaller workloads | Strong for stable or I/O-intensive load |
| Failure model | Consider instance and platform | Consider hardware and replacement process |
A production system may start on one host when the application accepts a documented maintenance and failure window. Higher availability objectives require a different architecture: separate failure domains, replication, load balancing and tested failover. Multiple containers on one host do not create high availability.
Sizing: user count is not enough
Relevant drivers include:
- PostgreSQL size and growth
- concurrent database connections
- query complexity and runtime
- Realtime connections and event rate
- upload, download and Storage volume
- Edge Functions and resource demand
- background jobs, webhooks and imports
- expected peak load
- backup and recovery duration
Plan CPU, memory, IOPS, local capacity and network together. PostgreSQL often benefits more from enough RAM and stable Storage latency than a headline virtual CPU count.
A practical baseline architecture
A clearly bounded application may start with:
- Hetzner Cloud or dedicated server in the intended region
- hardened Linux and restrictive firewall
- Docker Compose or a controlled Coolify instance
- reverse proxy with TLS and an owned Supabase domain
- Supabase services with pinned image versions
- local or external PostgreSQL according to architecture
- Storage backend and independent backup target
- monitoring, logs and alerting
- private administration through VPN or restricted access
Do not expose Studio and internal administration endpoints publicly without a reason.
Direct Docker Compose or Coolify?
Official Supabase documentation describes Docker as the self-hosting path. Hetzner also publishes a community tutorial for Supabase with Coolify.
Direct Docker Compose:
- stays close to the official template
- makes changes and overrides explicit
- supports a Git-based infrastructure workflow
- requires owned operational and deployment automation
Coolify:
- provides a central interface for deployments and domains
- can simplify app and platform administration
- works well for multiple managed workloads
- adds a management layer that also needs backup and updates
Coolify does not replace Supabase release assessment, PostgreSQL backup, Storage protection or recovery testing.
Networking and public exposure
Only endpoints genuinely required by the application and Auth flows need public access. Review:
- DNS and TLS
- API gateway and allowed origins
- OAuth redirects
- SMTP and email links
- webhooks and external callbacks
- administrative access
- direct PostgreSQL connections
- private networks to apps or backends
Administrative access can use managed NetBird or another controlled VPN path. Database ports and Studio should not be opened to the internet by default.
Storage decision
Supabase Storage needs a location for object bytes in addition to PostgreSQL metadata. Depending on stack and requirements, use local volumes or a compatible object-storage target.
Assess:
- expected volume and growth
- throughput and object sizes
- access latency
- redundancy
- lifecycle and deletion
- storage and transfer cost
- independent backup and recovery
Local storage on one server is simple but shares its failure domain. External object storage does not automatically solve backup and consistency.
Backup and recovery
Dependable operations protect separately:
- PostgreSQL including Auth and metadata
- Storage file bytes
- Compose, Coolify and proxy configuration
- Function code and schema migrations
- recovery procedures for secrets, OAuth, SMTP and domains
Copies do not live exclusively on the same server. A recovery test confirms database state, Storage objects and application work together. See back up Supabase completely for the full design.
Monitoring and continuous operations
Technical monitoring covers:
- API and Auth availability
- CPU, RAM, disk, I/O and network
- PostgreSQL connections, locks and errors
- container state and restarts
- Storage capacity
- Function and gateway failures
- backup success and age
- TLS certificates
Synthetic user journeys add value, such as login, a read-only API request and a controlled file download. They detect failures that container health checks miss.
Updates and ownership
With self-hosting, Supabase does not automatically own:
- version review
- reconciliation of official and local configuration
- protection before changes
- staging and compatibility testing
- maintenance windows
- smoke testing and rollback
A managed-service model defines patch cycle, monitoring, backup controls, incident response and change process. See update self-hosted Supabase.
Compare cost realistically
Server price is one line in total operating cost:
- compute and primary Storage
- object or backup Storage
- monitoring and log retention
- setup and migration
- updates and security review
- incident response
- recovery tests
- capacity changes
A fair comparison with Supabase Cloud uses equivalent backup, availability and ownership requirements. Supabase cost: Cloud vs self-hosted explains the full model.
