Where Should You Host ZITADEL? A Guide to Cloud-Native Identity Infrastructure

Florian Forster
Florian Forster

Founder and CEO

  1. Where Should You Host ZITADEL? A Guide to Cloud-Native Identity Infrastructure
    1. ZITADEL Cloud: The "Auth0 Alternative"
    2. Public Cloud (Managed Services): Data Sovereignty & Efficiency
    3. Full Self-Hosting: The "Keycloak Alternative" for Kubernetes
      1. The "Minimum Viable ZITADEL" Stack
    4. Summary

Where Should You Host ZITADEL? A Guide to Cloud-Native Identity Infrastructure

I love Open Source. It’s the foundation of everything we do at ZITADEL. I love that you can pull our containers, run our lightweight, Go-based API and NextJS Login UI on a Raspberry Pi, and have a fully functional Identity Provider (IdP) in minutes. But when I talk to CTOs and Engineering leads about securing production data and ensuring 99.99% uptime for their Multi-Tenant SaaS applications, the conversation shifts from "what can run" to "where should I deploy ZITADEL?"

I get asked constantly: "Florian, should I use your cloud? Should I run it on AWS? Can I just stick it in Docker Compose on a VM?"

The answer, as always in engineering, is: It depends on your requirements.

Here is my no-nonsense guide to choosing where to host ZITADEL, based on what I’ve seen work (and fail) in the real world.

ZITADEL Cloud: The "Auth0 Alternative"

If your team is lean, your deadlines are tight, or you simply don't want to wake up at 3 AM because a database vacuum process stalled, ZITADEL Cloud is my recommendation.

It is the same code we open source, but we handle the hard stuff for you:

  • Global Scale: We run clusters across multiple zones and regions.
  • Security: We handle the patching, the WAFs, and the DDoS protection.
  • Compliance: We are ISO 27001 and SOC 2 certified. Check out trust.zitadel.com—we worry about the audits so you don't have to.

My Verdict: Use this if you need a SaaS Identity solution that just works. It’s the fastest way to get to production and lets your team focus on your core product, not operating an IdP.

Public Cloud (Managed Services): Data Sovereignty & Efficiency

If you are already spending money on AWS, Azure, or Google Cloud, you shouldn't be fighting your infrastructure. You should be leaning into it.

This path is distinct from "self-hosting" because you aren't managing the heavy infrastructure yourself. You rely on the Managed Services (PaaS) that your cloud provider offers. ZITADEL is cloud-native by design, so if you are on a public cloud, you already have the two things ZITADEL needs to thrive:

  • Managed Compute: Use EKS, GKE, or AKS. Let the cloud provider handle the control plane upgrades and node scaling.
  • Managed Database: Use Amazon RDS for PostgreSQL, Cloud SQL, or Azure Database for PostgreSQL.
    • Tip: Do not host your own Postgres cluster here. Use the managed service to handle backups, failover, and point-in-time recovery out of the box. ZITADEL supports Postgres 14-17.
  • Managed Caching (Optional): If you are running high loads, plug in a managed Redis (like ElastiCache or Memorystore) to handle caching.

Why this is vital for Regulated Industries (Defense, Finance, Healthcare) & Global Apps: This setup is often the only choice for highly sensitive fields or high-performance requirements because it guarantees capabilities we can't always offer in SaaS:

  1. Zero Access to PII: You retain absolute sovereignty over your user data. We (ZITADEL) have no access to your PII, satisfying strict data residency and privacy requirements.
  2. Release Schedule Control: You aren't forced to upgrade on our schedule. You control the versioning, allowing you to align updates with your internal compliance audits or release freezes.
  3. Geo-Location & Latency Control: You can deploy in any region—even those where our SaaS doesn't have a presence—to ensure ultra-low latency for your local users. This is critical for gaming, edge computing, or real-time applications where every millisecond counts.

My Verdict: This is the "Best of Both Worlds." You keep data sovereignty and control inside your own VPC, but you offload the heavy lifting of database and kubernetes management to the cloud provider. Since ZITADEL supports zero-downtime updates, your team can focus entirely on the application lifecycle—deciding when to upgrade—without sweating the infrastructure details.

Full Self-Hosting: The "Keycloak Alternative" for Kubernetes

This is where things get interesting. I see a lot of users running ZITADEL in homelabs or on bare metal in private data centers. I love this use case because ZITADEL's architecture makes it incredibly efficient compared to legacy IdPs. But I have one Golden Rule:

⚠️ Docker Compose is for Development (and homelabs), Not Production.

We provide a docker-compose.yaml to help you try ZITADEL locally. It is great for spinning up an instance on your laptop to test things like OIDC flows. However, I cannot recommend it for production. It doesn't handle zero-downtime updates, it doesn't self-heal, and it lacks the resilience required for an identity system in a production setting.

The "Minimum Viable ZITADEL" Stack

If you want to self-host in production (whether in a homelab or an air-gapped data center), you need a stack that provides resilience.

Here is the what I recommend:

  1. Orchestrator: Kubernetes.
    • It doesn't have to be massive. A lightweight distro like K3s or K0s works perfectly for smaller setups. It gives you the rolling updates and service discovery we rely on.
    • Pro Tip: Use our official Helm Charts to streamline the deployment.
  2. Database: PostgreSQL (v14-17).
    • If you are on bare metal, use a robust operator like CloudNativePG (CNPG) to manage replication and backups.
  3. Networking: A Reverse Proxy with HTTP/2 & TLS.
    • ZITADEL uses gRPC heavily. Your proxy should support HTTP/2 and end-to-end TLS.
    • Traefik, NGINX, or Caddy are all excellent choices.

System Specs (Minimum):

  • CPU: 1 vCPU (I recommend 2-4 vCPUs to handle password hashing spikes without latency).
  • RAM: 512MB (Give it 1GB+ if you want breathing room).

My Verdict: Self-hosting gives you ultimate control and a modern Keycloak alternative, but it comes with the "You Run It" price tag. Ensure you have the Ops skills to manage a stateful database in Kubernetes.

Summary

SetupBest ForProsCons
ZITADEL CloudStartups, SaaS, Teams who want speedZero maintenance, High Availability & Managed Security, free tierLess control over the infrastructure and update cycles
Public Cloud (Managed Services)Enterprise, Compliance-heavy industriesData Sovereignty, Low Latency, leverages managed DB/K8s for stabilityRequires DevOps resources and knowledge
Self-HostedHomelabs, Air-gapped, Private MetalUltimate control, low memory footprint, lowest software costHigh operational overhead (You own the DB)

Ready to get started?

Liked it? Share it!