Skip to content

Zitadel

Summary

Zitadel is an open-source identity and access management (IAM) platform written in Go: OIDC (certified), OAuth 2.0, SAML 2.0, passkeys, MFA, SCIM 2.0, and a multi-tenant Instance > Organization > Project model built for B2B SaaS. State is stored as an append-only event log in PostgreSQL (event sourcing + CQRS), which gives a complete audit trail. The current line is v4 (v4.19.1, 2026-09-23); v3 is end of life. The core has been AGPL-3.0 since v3 (2025), while the API definitions stay Apache-2.0 and the Login V2 app and client packages are MIT. It runs self-hosted (Docker Compose, Helm) or as Zitadel Cloud, which runs the same codebase.

Back to Secrets

Key Facts

Attribute Detail
Website zitadel.com
Latest Version v4.19.1 (2026-09-23); v4.0.0 GA 2025-07-31
Previous lines v3.4.15 (2026-08-14) was the last v3 patch; v3 is end of life (advisory of 2026-09-24). v2 is end of life
Next major "Next iteration" in preview; roadmap targets H2 2026 capabilities and a 2027 production rollout with migration tooling. v4 supported for at least 12 more months
Language Go 1.25 (API server); TypeScript/Next.js (Login V2); Angular (Management Console)
License AGPL-3.0-only core (since v3.0.0, 2025-05-02; Apache-2.0 before). proto/ Apache-2.0; apps/login and client packages MIT. Commercial license on request
Vendor ZITADEL, a Swiss company; Zitadel Cloud regions US, EU, AU, CH
Database PostgreSQL 14 to 18 only (CockroachDB removed in v3)
Release cadence About one minor per month on v4, patches in between; semantic versioning
Pricing Self-hosted free; Cloud Free (100 DAU), Pro from $100/month (25,000 DAU included), Enterprise custom
Certifications OpenID Connect certified OpenID Provider

Architecture at a Glance

A proxy sends /ui/v2/login to the Next.js Login V2 container and everything else (APIs, OIDC/SAML endpoints, Console) to the stateless Go binary, which writes events to PostgreSQL and serves reads from projected tables.

flowchart LR
    RP["Apps (OIDC / SAML)<br/>and service accounts"] --> PX["Proxy / Ingress<br/>(h2c upstream)"]
    PX -->|"/ui/v2/login"| LG["zitadel-login<br/>(Next.js)"]
    PX -->|"APIs, /oauth/v2, Console"| ZB["zitadel binary<br/>(Go, stateless)"]
    LG -->|"Session / OIDC v2 APIs"| ZB
    ZB -->|"push events"| ES[("PostgreSQL<br/>eventstore.events2")]
    ES -->|"projections"| PR[("projections.*")]
    ZB -->|"queries"| PR
    ZB -.->|"Actions V2"| TG["Your webhook targets"]

Details: Explanation.

Why Zitadel

  • Event-sourced storage: every change is an immutable event, so the audit trail is complete by construction (see Event Sourcing Pipeline).
  • Multi-tenancy as a primitive: instances for hard isolation, organizations for B2B customers, project grants for delegated role management.
  • Passkeys first: FIDO2/WebAuthn as a primary login method, plus TOTP, U2F, email and SMS OTP.
  • API-first: every Console feature is available over gRPC, Connect, and (for most services) REST; the v2 Session API lets you build your own login.
  • Replaceable login: Login V2 is a separate MIT-licensed Next.js app built only on public APIs.
  • Same code for SaaS and self-hosting: Zitadel Cloud and self-hosted run the same codebase.

When Zitadel Fits

Scenario Fit
B2B SaaS needing multi-tenant auth with org-level delegation Excellent: organizations, project grants, per-org IdPs and branding, domain discovery
Replacing Auth0 with something self-hostable Strong: OIDC certified, similar developer experience, same code in Cloud
Replacing Keycloak with a lighter, API-first tool Strong: single Go binary, gRPC/REST APIs; Keycloak still has a larger ecosystem
CIAM with passwordless and passkeys Strong
Enterprise SSO with SAML 2.0 and SCIM provisioning Good: SAML IdP, SCIM 2.0 server, LDAP and Entra ID federation
Teams that must avoid AGPL obligations for a modified, network-served fork Weak: needs legal review or a commercial license
Teams needing multi-region active-active writes Weak: PostgreSQL-only; multi-region relies on read replicas
Simple API key management for microservices Moderate: machine users and PATs exist, but it is an IdP, not a key vault

Use Cases

  • B2B SaaS authentication: one organization per customer, project grants for customer-managed roles.
  • Internal platforms: SSO for Kubernetes dashboards, CI/CD, and internal tools through OIDC.
  • Customer-facing apps: social login, passkeys, self-registration, hosted or custom login.
  • Compliance-heavy environments: event history as an audit log, streamable to a SIEM through Actions V2 event executions.
  • Platform engineering: Terraform provider (v3.8.x) for identity as code.

Licensing and Pricing

Edition License Cost (2026-09)
Self-hosted AGPL-3.0 core; Apache-2.0 protos; MIT login and client packages Free
Zitadel Cloud Free Proprietary service $0: 100 DAU, unlimited users, 3 IdPs
Zitadel Cloud Pro Proprietary service $100/month base with 25,000 DAU, then usage-based; 99.50% SLA
Extended Support and SLA add-on Proprietary $999/month; 99.95% SLA
Enterprise (Cloud or self-hosted license) Commercial Custom; suggested above 175,000 DAU

AGPL-3.0 implications

Running unmodified Zitadel, configuring it through the UI and APIs, and building your own login on the SDKs does not require publishing your code, according to the v3 licensing discussion (GitHub discussion 9529). Modifying the core and offering it over a network does. Zitadel's LICENSING.md recommends legal review. Full per-path table: Reference.

Versions and Support

v4 is the only supported line. v4.0.0 (2025-07-31) made Login V2 the default for new instances, took Actions V2 to GA, completed the resource-based v2 APIs for core resources, and added Service Ping (opt-out usage reporting). v3.0.0 (2025-05-02) changed the license and removed CockroachDB. The 2026-09-24 advisory GHSA-4hgj-wm6c-q7p2 states that v3 will not receive further patches, while the roadmap page still says a v3 end-of-life timeline "will be shared soon"; treat v3 as unsupported. The full matrix is in Reference.

Patch promptly

July to September 2026 brought several critical account-takeover advisories in Login V1 and V2 flows (for example GHSA-g8gj-gq47-xgf4, CVSS 9.8, fixed in v4.17.3). Run v4.19.1 or later and skip v4.18.0.

Ecosystem and Connections

  • Terraform provider zitadel/zitadel (v3.8.7, 2026-09-25): organizations, projects, roles, apps, IdPs, policies.
  • SDKs: Go (zitadel-go/v3), Python (zitadel-client, incubating), Node (@zitadel/node), React (@zitadel/react), and more. Framework guides cover Next.js, Angular, Django, FastAPI, and others.
  • SCIM 2.0 server for provisioning from Entra ID, Okta, and similar.
  • Actions V2 webhooks for token enrichment, request validation, and event streaming.
  • Observability: OpenTelemetry traces, metrics, and logs through the Instrumentation config; Prometheus metrics exporter.
  • Deployment: official compose pack (Traefik), Helm chart (Ingress or Gateway API), documented configs for NGINX, Caddy, Apache httpd.

Compatibility and Requirements

  • PostgreSQL 14 to 18, the only supported database (18 needs v4.11.0+). See PostgreSQL.
  • CockroachDB: removed in v3.0.0; migrate with zitadel mirror. See CockroachDB.
  • Redis: optional cache, standalone mode only.
  • Kubernetes 1.30+ with Helm 3 or 4, or Docker Compose v2.
  • A reverse proxy that forwards HTTP/2 (h2c) to the API.

Full requirements: Reference.

Alternatives

Tool Key difference
Keycloak Java, CNCF incubating, largest self-hosted ecosystem; realm-based multi-tenancy; Apache-2.0
Auth0 Commercial SaaS (Okta), no self-hosting
Ory Hydra and Kratos Separate headless components (OAuth server, identity service); you build the UI
Authentik Python/Django, strong admin UI and proxy outposts, popular for homelabs
Casdoor Go, simpler, lighter multi-tenancy
FusionAuth Self-hostable but not open source; tenant model similar to Zitadel instances

Migration and Lock-in

  • From Auth0 or Keycloak: OIDC and SAML standards keep app changes small. Users can be imported with password hashes (bcrypt, argon2, scrypt, pbkdf2, sha2, md5 variants, phpass, drupal7) and are re-hashed on login.
  • Out of Zitadel: user data is reachable through the APIs and the event log; there is no one-click export to another IdP.
  • Database: standard PostgreSQL without proprietary extensions.
  • Login: the Session API lets you own the login UI, reducing UI lock-in.

Community Health

Metric Value
GitHub stars ~13.5k (as of 2026-04)
License AGPL-3.0 (core)
Primary language Go
Community chat Discord (zitadel.com/chat)
Release activity 19 v4 minor releases between 2025-07 and 2026-09
Security process Coordinated disclosure via zitadel.com/vulnerability; GitHub advisories
OpenSSF Best Practices Project 6662 (badge in README)

Topic Map

  • How-to Guides: deploy with Compose or Helm, managed PostgreSQL, proxy, caching, observability, v3 to v4 upgrade, backups, v2 APIs, SDKs, Terraform, Actions V2, troubleshooting.
  • Reference: versions and support, licensing by path, Cloud pricing and SLA, requirements, endpoints, config keys, roles, schema, advisories, hardening checklist.
  • Explanation: component topology, the separate Login V2 app, API surface, event-sourcing pipeline, session and authorization flows, Actions, multi-tenancy hierarchy, deployment topologies, security model.

Sources

Questions

Answered

How does Zitadel compare to Keycloak? Zitadel is a Go binary with event sourcing and CQRS and an API-first design (gRPC, Connect, REST from protobuf); Keycloak is Java with CRUD over an RDBMS and a larger ecosystem. See Alternatives.

Can Zitadel handle multi-tenant B2B SaaS? Yes. Organizations isolate tenants inside an instance, and project grants let a customer's admins manage the roles you delegate. See Multi-Tenancy Hierarchy.

Is Zitadel production-ready? Yes for v4 on PostgreSQL, with the caveat that its login flows had a cluster of serious advisories in mid-2026, so patch discipline matters. Zitadel Cloud offers a 99.50% default SLA and 99.95% with the extended SLA.

Does Zitadel support SAML 2.0? Yes, as an IdP, and it can federate to external SAML IdPs.

How does projection lag affect authorization? For lookups by ID the query side can trigger the projection first so it reads the latest events for that ID; list queries can be slightly stale. Permission checks read projected memberships, so a just-granted role can take effect after the projection catches up. Source: software architecture docs.

How do Actions V2 differ from V1? V1 runs JavaScript inside the Zitadel process (goja); V2 calls your HTTP endpoints for requests, responses, functions, and events, isolated from Zitadel. V1 is deprecated and its APIs are to be removed in the next major. See Actions & Webhooks Pipeline.

Open

  • Migration path from v4 to the next major: the roadmap promises incremental migration tooling with a 2027 production rollout, but no breaking-change list or version number is published yet.
  • Token revocation at scale: JWT access tokens cannot be revoked before expiry without introspection; what lifetime and introspection mix Zitadel recommends at high request rates is not documented.
  • Event log growth: there are no official figures for event-store size, write amplification, or projection rebuild times at millions of users.
  • Actions V2 latency: no published numbers for the latency added by synchronous restCall targets in the login path.
  • v3 end-of-life date: the security advisory says v3 is end of life, but the roadmap still says "We'll be sharing V3's EOL timeline and upgrade guidance soon". Not published: no official v3 EOL date as of 2026-09-28.