Need the control of a dedicated environment without operating Supabase internally? WZ-IT provides managed Supabase on managed, customer-controlled or on-premises infrastructure.
Self-hosting Supabase does not make sense merely because Docker Compose can start the stack. The actual difference from Cloud is operational ownership. Self-hosting provides control over infrastructure and data paths, but also transfers updates, backups, monitoring, scaling and recovery to the operator.
Main advantages
Control over location and network
The platform can run in a European cloud, on dedicated hardware, in a company data centre or in an isolated environment. Private networks, VPNs, internal APIs and databases can be connected directly.
Dedicated resources and explicit sizing
CPU, memory, storage and network can be selected for the actual workload. PostgreSQL, storage or functions may be separated when needed. This is particularly useful when a company already has infrastructure and a capable platform team.
Integration with existing operations
Self-hosted Supabase can connect to central services:
- monitoring and log management
- secrets management
- SMTP and identity providers
- object and off-site storage
- backup and recovery processes
- CI/CD and configuration management
- private access and site connectivity
Technical portability
PostgreSQL is an established standard. The data model, SQL functions and many extensions remain useful outside Supabase. This reduces dependency at the database layer, but does not automatically remove dependencies on Auth, Storage, Realtime or the Data API.
Main drawbacks
A stack of multiple services
Supabase is not just PostgreSQL. The self-hosted stack includes Auth, Realtime, Storage, Studio, Functions, pooling, a gateway and logging. Versions and configuration across these services need to be maintained together.
No managed backups or PITR by default
The self-hosting documentation explicitly lists managed backups and Point-in-Time Recovery as unavailable. PostgreSQL dumps, physical backups or WAL archiving must be implemented separately. Storage files need their own protection path as well.
Updates become operational projects
Supabase now provides update.sh with version tracking and a three-way merge. The script does not back up PostgreSQL or Storage data. Older or heavily customised installations can require manual conflict resolution and separate PostgreSQL upgrades. The official update guide explains these boundaries.
Cloud capabilities are absent or different
Self-hosting does not automatically provide branching, advanced platform metrics, managed backups/PITR, analytics and vector buckets, ETL or the platform management API. Functions run on the local runtime rather than an automatically distributed global network.
Availability belongs to the operator
A single Docker host is a single point of failure. High availability across PostgreSQL, Storage, the gateway and other services is substantially more complex than adding another VM. RTO, RPO, load and accepted downtime should be defined before selecting an architecture.
Recurring responsibilities
| Area | Ongoing responsibility |
|---|---|
| Host | OS, kernel, firewall, Docker and capacity |
| Supabase services | Versions, configuration, compatibility and health checks |
| PostgreSQL | Performance, connections, vacuum, extensions and upgrades |
| Auth | Providers, SMTP, redirects, keys and sessions |
| Storage | Capacity, consistency, object backup and permissions |
| Security | RLS, grants, secrets, Studio access and vulnerabilities |
| Recovery | Database, storage, configuration and restore tests |
| Incident response | Alert intake, diagnosis, recovery and communication |
When self-hosting fits
Self-hosting is often appropriate when several of these statements apply:
- There is a concrete location or network-isolation requirement.
- Private systems and data paths need direct integration.
- A platform team or managed-service provider is available.
- Backup, monitoring and incident processes already exist.
- Load and capacity are sufficiently understood.
- Missing Cloud features have been assessed.
- Cost is evaluated as total operational effort.
When Cloud is usually the better choice
Supabase Cloud often remains the better option when:
- the product has no stable usage profile,
- a small development team cannot provide platform on-call coverage,
- Cloud branching and managed platform capabilities are important,
- infrastructure savings would be small,
- there is no location constraint,
- recovery and updates cannot be operated reliably.
Self-hosting should solve an operating-model requirement rather than merely remove a monthly Cloud invoice.
Managed self-hosting does not remove every responsibility
A managed service still leaves business decisions with the customer: which data may run where, what downtime is acceptable, which identity providers are used and who approves application changes. A provider owns technical tasks within a confirmed scope, not the business responsibility for the application.
An assessment should therefore inventory Cloud capabilities, data volumes, auth, storage, functions and operational objectives before migration. The result may be a dependable self-hosting design or a well-supported decision to stay in Cloud for now.
