Skip to content
Documentation
  • There are no suggestions because the search field is empty.

Self-Hosting ZITADEL: Operational Overhead & Resource Guide

A quick breakdown of ZITADEL self-hosting infrastructure requirements, the  patching cycle, and estimated engineering resource allocation.

For teams already experienced with containerized workloads, infrastructure as code (Terraform), and CI/CD pipelines, self-hosting ZITADEL is highly predictable.

Here is a concise, high-level breakdown of the administrative overhead, patching cadence, and people resources required.

Infrastructure Footprint

Compute
Extremely lightweight. Containers require 512MB–1GB RAM minimum. While they can run on less than 1 CPU core, 2–4 vCPUs are recommended to absorb short CPU spikes during password hashing.
 
Database
Backed by PostgreSQL (versions 14 to 18 supported). ZITADEL uses an event-driven, relational architecture, eliminating the need for complex external session caches for basic horizontal scaling.
 
Caching (Optional)
Redis can be plugged in to speed up lookups of frequently accessed objects under high loads.
 

Maintenance & Patching

To minimize upgrade friction, ZITADEL coordinates changes around a structured schedule:

  • 3-Month Major Releases: Significant features and database migrations are batched into predictable, quarterly blocks.
  • 6-Month Support Window: Major versions receive active support and critical patches for roughly six months before hitting deprecation, providing a clear upgrade path.
Database migrations are native to the codebase and split between init and setup phases, fully supporting zero-downtime rolling updates during standard production windows.

Custom workflows and token enrichments are handled via ZITADEL Actions (JavaScript) in the runtime environment. Changes deploy immediately without rebuilding images or restarting containers.
 

Human Resource Allocation (Medium Deployment)

 For an experienced engineering and platform team, a medium deployment of ZITADEL (ie, a highly available environment serving roughly 10,000 - 100,000 MAUs with multi-region or multi-zone fault tolerance) shouldn't require a dedicated, full-time Engineer.


Because your team already handles modern infrastructure well (Kubernetes, IaC/Terraform, CI/CD), ZITADEL will quickly shift from a "project" to a "background utility."

A realistic allocation of your team's resources across the lifecycle of a medium deployment breaks down into specific phases: 

Phase Resource Allocation Duration / Frequency Primary Tasks
Phase 1: Initial Build 0.5 to 1.0 FTE
Platform/ DevOps Engineer		 2 to 4 weeks IaC, HTTP/2 ingress/gRPC routing setup, secrets integration, and DB provisioning.
Phase 2: Steady State 2–4h /week

 Ongoing Monitoring alerts (Prometheus/Grafana), backup verification, and minor configuration updates, security patches.
Phase 3: Upgrades 4-8 hours
 Every 3 Month Reviewing major release notes, testing migrations in staging, and running production deployment.

The Primary Variable: Database Operations

Your ongoing maintenance overhead depends almost entirely on your database management strategy:

The Managed Route (Low Overhead)
Pairing ZITADEL with a cloud-managed database (e.g., AWS RDS, Google Cloud SQL) keeps operational needs at a minimum, as the cloud provider handles replication, backups, and point-in-time recovery.
 
The Self-Managed Route (Higher Overhead): Running high-availability PostgreSQL on-premise or via Kubernetes operators (e.g., CloudNativePG) will add an extra 0.2 to 0.4 FTE to manage replication lag, connection pooling, and storage scaling.

If offloading 24/7 infrastructure scaling, multi-region compliance management, and runtime monitoring is preferred, ZITADEL Cloud runs the exact same codebase out-of-the-box, removing the infrastructure layer entirely.