Keycloak vs Zitadel

Keycloak and Zitadel both do the job of a full-scale identity platform — SSO, OIDC, SAML, and a real admin surface for managing who can log into what. The difference is a decade of production history versus a design built for how identity gets used today. Keycloak is the JVM-based incumbent: Red Hat-backed, CNCF-incubated, the deepest SAML and LDAP implementation in open source. Zitadel is often described as "a modern Keycloak" — Go-based, API-first, multi-tenant and passwordless from the ground up. Neither is a lightweight choice, but if you're picking between these two rather than reaching for authentik, this is the matchup that decides it.

The enterprise standard vs. a modern rebuild

Keycloak has been running identity for banks, governments, and large enterprises for well over a decade. It's built on Java and Quarkus, organizes tenants into "realms," and its SAML and LDAP/Active Directory federation are widely regarded as the most complete available in open-source identity software — the kind of depth that matters when you're integrating a legacy enterprise app that insists on SAML and nothing else. Its admin console is comprehensive, if dense: realms, clients, scopes, and mappers are all powerful primitives, but a first OIDC integration takes real time to get right.

Zitadel starts from the same problem space with a different set of priorities. It's a single Go binary backed by PostgreSQL, and it's multi-tenant by construction — organizations are a first-class concept, not something bolted onto a realm model after the fact. Passwordless and passkeys are the default sign-in path rather than an add-on, and its API-first design means most of what the admin UI can do, your own code can do too. It covers the same protocol core as Keycloak — OIDC and SAML — but without Keycloak's decades of accumulated edge-case coverage.

Resource usage and setup effort

Both fixtures quote a 1 GB minimum, and both rate a demanding 4 out of 5 to deploy — on paper, they look evenly matched. In practice, the reasons differ. Keycloak's low quoted minimum describes its dev-mode quickstart: a single container with an embedded database that really is that light. Getting it production-ready — an external database, correctly sized JVM heap, clustering — is where the difficulty rating comes from; the JVM asks more of you the closer you get to a real deployment. Zitadel's difficulty comes from a different place: the container count is smaller and there's no JVM to tune, but you're asked to think in organizations and projects from your very first login, which is real conceptual overhead even without Keycloak's production-tuning curve.

Measured idle at first boot only tells half the story here, because only one side of it is actually measured. A fresh Zitadel instance — its Compose quickstart: Zitadel, PostgreSQL, a login container, and a small proxy — settles at ~233 MB idle. Keycloak's own dev-mode quickstart runs in the foreground and isn't unattended-installable the same way, so there's no equivalent measured number for it; its docs describe a ~750 MB minimum container memory limit and recommend ~2 GB for smaller production-ready deployments. Those are two different kinds of figure — one measured on an idle box, one documented by the project — so don't read the gap as precise. But even against Keycloak's own stated minimum, Zitadel's measured idle footprint is smaller, and the pattern matches what the deployment-difficulty gap already suggests: Zitadel's number is close to fixed by its small set of always-on containers, while Keycloak's real number depends heavily on how production-seriously you deploy it.

Protocols and standards

This is Keycloak's strongest ground and it isn't close. Its SAML implementation is mature enough to be the safe default when you're integrating an app that speaks nothing else, and its LDAP/Active Directory federation is about as complete as open-source identity gets. Support for newer OAuth2/OIDC profiles like PAR and DPoP exists but is still filling in. Zitadel covers OIDC, OAuth2, and SAML solidly, and leads on the newer side — passwordless and passkey flows are native, not retrofitted — but it has not accumulated Keycloak's breadth of legacy-protocol edge cases. For straightforward OIDC SSO across self-hosted apps, that gap rarely shows up. For federating against an existing enterprise directory, Keycloak is the safer bet.

Maturity and ecosystem

Keycloak's production history is difficult to match: it has run identity for enterprises, governments, and financial institutions for years, has a large global contributor base, and Red Hat's backing gives it an unusually strong "still around in five years" signal. That maturity shows up in the ecosystem too — more third-party guides, more integration write-ups, more Stack Overflow answers for the edge case you eventually hit. Zitadel is younger and has less production mileage at the largest scales — expect to blaze a few more trails yourself than you would with Keycloak. Its documentation is strong and its API-first design means a lot of that trailblazing happens through code rather than trial-and-error clicking, which softens the gap somewhat for teams comfortable automating their setup.

Licensing

Keycloak is Apache-2.0 — permissive, no commercial gate, the entire feature set lives in the open project, and Red Hat's commercial offering is support rather than functionality. Zitadel is AGPL-3.0, a real selection criterion for some organizations: it's rarely a practical issue for internal, self-hosted use, but it requires publishing your modified source the moment you offer a modified Zitadel as a network service to outside users. If avoiding AGPL entirely is a hard requirement, that alone settles this comparison in Keycloak's favor regardless of footprint.

Who should pick neither

If your actual need is SSO for a handful of self-hosted apps rather than an enterprise-grade identity platform, both of these are more than the job calls for. authentik covers the same protocol core with a lighter, more self-hoster-friendly setup — see authentik vs. Keycloak — and if you don't even need a directory, Pocket ID or Authelia go much lighter still.

Choosing between Zitadel and Keycloak

Start from Keycloak's side and the decision reverses cleanly: reach for it first only if you need the deepest SAML or LDAP/Active Directory federation available in open source, you're integrating a legacy enterprise app or directory that insists on it, AGPL is a hard no for your organization, or Red Hat's backing and a decade of production history matter specifically to you — and you're willing to feed it a properly sized, externally-databased JVM to get there. Outside of those specific reasons, Zitadel is the better default between these two: its measured ~233 MB idle footprint, API-first design, and native multi-tenancy and passwordless support cover what most self-hosted identity needs actually require, without Keycloak's production-tuning tax. Neither replaces authentik as the general-purpose recommendation for self-hosters gating their own app stack — see authentik vs. Zitadel for that comparison — but between these two specifically, Zitadel is the one to start with unless Keycloak's specific strengths are the ones you need.

Running either on a VPS

Both belong on a properly sized server, not the bare documented minimum. Keycloak in particular needs a production-shaped setup — an external database, sane JVM heap sizing — rather than its dev-mode quickstart if you're running it for real; budget accordingly and expect its JVM to reward tuning attention as your realm grows. Zitadel needs its PostgreSQL database provisioned from the start, since it's event-sourced and that database is the permanent source of truth for every identity you create — back it up like it matters. Either stack fits on any of the VPS options here, and the step-by-step install guides are linked below.