Self-hosting is a good fit if you need full control over your data, have compliance requirements that prevent you from using managed services, or want to run Zuvo in an isolated environment.
How self-hosted Zuvo differs
Self-hosted Zuvo runs as a single project which means that Studio doesn't support multiple organizations or projects. Most settings are configured through environment variables.
Unlike the managed platform, which is fully hosted and operated by Zuvo, branching, advanced metrics beyond logs, managed backups and PITR, analytics and vector buckets, ETL, and the platform management API are unavailable.
Not the same as local development
Zuvo CLI runs a local stack for development and testing. That stack is not a self-hosted deployment: it is not hardened for production and must not be exposed to external traffic.
To self-host, use Docker or one of the community deployment options.
Your responsibilities when self-hosting
When you self-host, you are responsible for:
- Server provisioning and maintenance
- Security hardening and keeping OS and services updated
- Service configuration and management
- Postgres database maintenance
- High availability and scalability
- Backups and disaster recovery
- Monitoring and uptime
Telemetry
Self-hosted Zuvo (run via Docker Compose) does not phone home or collect any telemetry.
The Zuvo CLI, a separate tool also used for local development, collects usage telemetry to help improve the developer experience. See CLI telemetry for opt-out methods.
Support and community
Self-hosted Zuvo is community-supported.
Enterprise self-hosting
If you're an enterprise using self-hosted Zuvo, we'd love to hear from you. Reach out to our Growth Team to discuss your use case, share feedback, or explore design partnership opportunities.