Sign-in and accounts for SaaS and B2B platforms
Zitadel is an identity and access management (IAM) server written in Go. Applications hand user sign-in over to it through OpenID Connect or SAML, and it keeps the accounts, roles and sessions. The project targets SaaS products and B2B platforms that serve many customer companies at once. You can run it yourself or use Zitadel Cloud, which runs the same codebase.
The comparison of self-hosted SSO tools places Zitadel and its licence among the other identity providers.
Nested tenants where customers hand out their own roles
- Tenancy at two levels: an instance (one domain, one token issuer) holds organizations whose users and data are kept apart. Each organization can bring its own identity providers, password policy, MFA rules and branded login page. Extra "virtual" instances are created through the system API, for when your customers have customers of their own who want their own domain.
- Customers hand out roles themselves: a partner organization can grant the roles of one of your projects to its own users without going through you.
- OIDC, SAML and SCIM: certified OpenID Connect provider, SAML 2.0, a SCIM 2.0 server for provisioning, device authorization and token exchange. Users can also sign in through an LDAP directory, an enterprise identity provider or a social account.
- MFA: FIDO2/WebAuthn passkeys, U2F keys, TOTP apps, and one-time codes by email or SMS.
- Every change is an event: each mutation is stored as an immutable event you can browse in the console, query through the API or push to a SIEM with webhooks.
AGPL since v3, with PostgreSQL as a hard requirement
Zitadel has been AGPL since v3, not Apache 2.0. The repository was Apache 2.0 through the 2.x line, and those releases keep that license. The switch to AGPL-3.0-only was announced on March 13, 2025 and shipped with v3.0.0 on May 2, 2025, so articles that still call Zitadel Apache-licensed describe the old state. A few directories are carved out: the proto definitions and the docs stay Apache 2.0, while the login UI and the client packages are MIT. The vendor's licensing FAQ says shipping Zitadel unmodified is generally fine; to keep your modifications private, the vendor sells a commercial license. Keycloak, which Zitadel's README compares itself against in a table, is still Apache 2.0.
PostgreSQL is mandatory, and v4 ships as containers. Zitadel needs PostgreSQL 14 through 18; CockroachDB support was dropped in v3. The official Docker Compose stack runs two services, the Go API and a Next.js login UI, behind Traefik, and any other reverse proxy works if it speaks HTTP/2 to the upstream. Redis is optional. The docs pitch Compose for trials and homelabs, send production to the Helm chart on Kubernetes, and warn that the Linux binary install guide does not work with v4. If all you need is a login page in front of a few self-hosted apps, VoidAuth runs as a single service and accepts SQLite.
The database and password hashing cost more than Zitadel itself. The docs put Zitadel at about 512 MB of RAM and under one CPU core, but recommend keeping 4 cores available for password-hashing spikes. The database needs roughly one core and 4 GB of RAM per 100 requests per second. The Compose guide asks for a machine with at least 2 GB of RAM, and the recommended high-availability setup is three nodes with 4 cores and 16 GB each.
Zitadel Cloud differs by quotas, not by code. The self-hosting page says the AGPL community edition includes all core features. The free cloud tier stops at 100 daily active users, one instance, three external identity providers and one day of audit trail history. Pro starts at US$100 a month with 25,000 daily active users included and two weeks of history. Data lives in the region you pick: EU, US, Switzerland or Australia. Enterprise, in the cloud or on your own infrastructure, adds the commercial license, a technical account manager, an uptime commitment and "commercial add-ons" the page does not spell out.
Eleven minor releases in 2026, and a rebuild in alpha. v4.19.4 shipped on October 1, 2026. Between v4.9.0 on January 6 and v4.19.0 on September 23 the project put out eleven minor versions, and the 3.4 branch still gets fixes (v3.4.15 on August 14, 2026). A next-generation codebase that rebuilds the storage core and the API is in alpha in a separate repository, zitadel/nextgen, and is meant to become the base of a future major version.