Both are open source. The license and the extension model decide it.

The arguments that carry a Keycloak comparison against a commercial platform — no per-user licence, no cloud-only deployment, source you can read — all apply to Zitadel too. It is a real open-source identity server, it self-hosts, and it is actively developed: 45 releases published so far in 2026 against Keycloak's 21.

Both of them, verified on the versions above:

• Implement OpenID Connect, OAuth 2.0 and SAML 2.0, and serve SAML IdP metadata.
• Support the device authorization grant, JWT bearer, token introspection and revocation, and back-channel logout.
• Sign with EdDSA, RSA and ECDSA, and publish a discovery document at a well-known URL.
• Federate to external OIDC and SAML providers, plus the usual social logins.
• Do SCIM 2.0 — Zitadel in the core product, Keycloak through the open-source Organizations extension we maintain.

So the honest version of this page is not "Zitadel is the cheap option and Keycloak is the real one." Zitadel is genuinely better at several things, and we say which in the last section. What follows is the set of differences that actually change an architecture.

We started both at their published quickstarts and read the discovery documents. No tuning, no feature flags, defaults only. Keycloak's document carries 56 keys, Zitadel's 29. Reproduce it in two commands:

# Keycloak 26.8.1
curl -s http://localhost:8080/realms/master/.well-known/openid-configuration

# Zitadel v4.20.0
curl -s http://localhost:8080/.well-known/openid-configuration

Read that table carefully, because a discovery document is not a feature list. Two of those rows prove it in opposite directions. Zitadel does implement RFC 8693 token exchange and RFC 7591 dynamic client registration — the registration endpoint only appears in discovery once it is turned on in the instance's security settings, which is visible in the server source, and token exchange is enabled per application rather than globally. Going the other way, Keycloak advertises the token exchange grant, but the legacy flavour that covers brokering and impersonation is still a preview feature and is disabled unless you ask for it. Both servers can do more than they say, and one of them says more than it does.

What the table is good for is the shape of each project. Keycloak's defaults carry the later OAuth hardening work — PAR, DPoP, mTLS-bound tokens, RFC 9207 — because large regulated deployments ask for it, and it also still ships the password grant, which Zitadel does not and which you should not be using either. Zitadel's defaults are narrower and in two places safer: S256-only PKCE and no ROPC are the choices you would make yourself.

Every identity project eventually needs logic that is specific to you: a check against an internal system before a user is created, a claim computed from somewhere else, a step in the login that nobody else has. The two answers are different enough to decide the whole choice.

If your team does not write Java, Zitadel's model is the better one and it is not close. Nothing in the server has to be rebuilt, the blast radius of a bad action is an endpoint you can roll back, and a Go or TypeScript shop stays in its own language.

The price is that the extension point is now a service: it needs to be deployed, kept up, authenticated, and kept fast enough to sit in a login. If it is down, the thing it was guarding is down with it. Keycloak's answer has the opposite shape: nothing extra to operate, no round trip, and far deeper access to the model, in exchange for writing Java and for a provider that can break on an upgrade because the SPIs it binds to are internal. One is an integration problem, the other is a maintenance problem. Pick the one your team already knows how to carry.

Zitadel is the better answer when:

• Footprint matters. Idle, immediately after start, on a 2-CPU 8 GB machine: the four containers of Zitadel's published compose stack came to about 249 MB, Keycloak's quickstart to about 611 MB. There are caveats in both directions. Keycloak sizes its heap from the memory limit it is given, and that figure is development mode with an embedded database while Zitadel's includes a real PostgreSQL. But a Go binary against a JVM is a real difference, and in a homelab or a small edge deployment it is the one you feel first.
• You are building multi-tenant SaaS and do not want to think about it. Instances and organizations are in the core product. Keycloak's realm model does not stretch to a realm per customer, which is why we maintain an organizations extension and wrote up the multi-tenancy options in full.
• Audit is a requirement rather than a feature. Event sourcing means the history is the storage model, not a log you enabled. Keycloak can get you there, but event storage is something you have to plan for.
• Nobody on the team writes Java, and the custom logic is more than a mapper.
• You want a maintained login UI you can fork. Zitadel's login app is a separate MIT-licensed Next.js service, and the seam is designed in rather than worked around.

Keycloak earns it when:

• Apache 2.0 is worth something to you — you embed, redistribute, or patch the server, and you would rather not be in a licensing conversation with its vendor.
• There is a directory. LDAP and Active Directory federation with writable edit modes, group mapping, scheduled sync and Kerberos is a large amount of work to not have to do.
• Your security review has a list. PAR, DPoP, mTLS-bound tokens, CIBA — present and advertised at the defaults.
• You need to reach into the model. 139 provider interfaces, and a custom authenticator that runs in-process rather than over a network hop.
• The ecosystem is the point. A CNCF Incubating project with many independent vendors behind it is a different kind of bet from a single-vendor project, both for support and for hiring people who have already run it.

And the honest closing note, which applies to either choice: the operations bill is real. Keycloak is a JVM application with a database, a cache and an upgrade cadence, and running it well is a job. That is the argument for managed Keycloak at a fixed monthly price rather than a per-user meter. If you would rather run it yourself, we also support teams who do. If residency is driving the decision, our EU data residency page states where identity data sits and where it does not, including the parts that are not flattering.