ZITADEL

An API-first, event-sourced identity and access platform that is multi-tenant from the first design, positioned between Auth0's developer experience and Keycloak's self-host control.

Category: Identity & Policy
CNCF maturity: Independent (not a CNCF-hosted project)
Language: Go (75.8%), TypeScript (11.7%, console and login UIs)
License: AGPL-3.0-only, with Apache-2.0 for proto/ and apps/docs/ and MIT for the login app and client SDKs
Repository: zitadel/zitadel
Documented at commit: 10087e7 (main, near tag v4.15.2, 2026-06-17)

What it is

ZITADEL is a self-hostable identity provider. It issues and validates OIDC, OAuth 2.0, and SAML 2.0 tokens, manages users and their authentication factors, and answers authorization questions through an RBAC model. It ships as a single Go binary backed by PostgreSQL, and the same codebase runs both the hosted ZITADEL Cloud and self-hosted deployments.

What sets it apart from a conventional IdP is the storage model. Every state change is written as an immutable event to an event store, and read models (projections) are built from that event stream (README.md:65). The result is a complete audit trail that is part of the data model rather than a separate log, and it can be streamed to external systems through webhooks.

It targets teams that need multi-tenancy as a built-in concept. The hierarchy of Instance, Organization, Project, and Application is baked into the event layer, so tenant isolation is a property of the data rather than a convention layered on top.

When to use it

You need a self-hosted IdP with B2B multi-tenancy (separate organizations, delegated administration) without building that layer yourself.
You need a tamper-evident, API-accessible audit trail of every identity change, not just a subset of logged actions.
You want one codebase that you can self-host and also consume as SaaS with parity.
You integrate over APIs: ZITADEL exposes every resource through gRPC, connectRPC, and HTTP/JSON from one service definition.

When it is a poor fit:

You need ZITADEL to act as an LDAP server or RADIUS endpoint. It can federate from an external LDAP as an upstream IdP, but it does not serve LDAP or RADIUS itself. Keycloak or Authentik fit better there.
You want a CNCF-governed project with vendor-neutral governance. ZITADEL is commercially driven and dual-licensed.

In this deep-dive

History: origin, milestones, and why it exists.
Architecture: components and how requests flow.
Adoption & Ecosystem: who runs it and what surrounds it.
Internals: the code paths that matter, read from source.
Getting Started: install and a first working setup.

ZITADEL ​

What it is ​

When to use it ​

In this deep-dive ​

Sources ​

ZITADEL

What it is

When to use it

In this deep-dive

Sources