Keycloak vs Zitadel: which to choose

Keycloak vs Zitadel: when each one is the right choice

Keycloak fits Apache-2.0 sign-on and federation across many applications, while Zitadel fits B2B products whose customers manage their own users. Your team is either embedding identity in a product that sells to other organizations, or running one identity platform for internal staff and the applications they use. Both platforms are on the shortlist, so the decision turns on four things: license obligations, the tenant model, database and audit requirements, and who will operate the platform day to day. Start with the license, because it is the one question you cannot easily fix later. Keycloak is licensed under Apache-2.0, and Zitadel moved to AGPL-3.0-only with v3 in April 2025, with a commercial license offered as an alternative. Have counsel review what AGPL obligations mean for your distribution model before you commit, and confirm the current terms in the Zitadel licensing document.

The tenant model is the second decision point. In Zitadel, an organization is comparable to a tenant in a SaaS system, and many organizations can sit inside one instance, which suits products whose customers administer their own users and login policies. Keycloak handles multi-tenancy differently, so if your design relies on customer-managed tenants, test that model in a prototype rather than assume it maps across. Database and audit needs come next. Keycloak needs a relational database in production, and Zitadel is built on event sourcing, which gives it a built-in audit trail of changes. If your auditors expect a complete change history from day one, Zitadel's design matches that expectation directly, but confirm how your retention and evidence requirements map to it. Finally, decide who runs the platform. Keycloak has a long operating history and an official Operator for Kubernetes and OpenShift, which suggests a broad pool of operators and documentation. Zitadel's operating model, its PostgreSQL 14 to 18 support, and its upgrade path are a smaller pool of practice, so ask your platform team which identity platform they can support at 2 a.m. during an incident. A fixed-scope implementation partner can help you test both designs against your real tenant and audit requirements before you choose.

Which scenario points to Keycloak and which to Zitadel

This table maps common scenarios to the platform that fits them better, with the condition under which the other platform would still be the stronger choice. Read each row against your own product model, licensing position and audit requirements rather than treating the table as a verdict. The main takeaway is that Zitadel's organization model and event-sourced history favor B2B products and change tracking, while Keycloak's Apache-2.0 license and long-established federation features favor internal SSO and embedded use without AGPL obligations.

Scenario	Better fit	When the other platform still wins
Internal workforce SSO for employees and internal apps	Keycloak	Zitadel fits if your team already wants its organization model and event history for workforce identity and accepts the AGPL-3.0-only terms.
SaaS product where each business customer manages its own users	Zitadel	Keycloak can work through realms or separate deployments, but it needs more design work to match Zitadel's organization-based model.
Embedding identity in a product distributed to others, without AGPL obligations	Keycloak	Zitadel can still fit if you can meet AGPL-3.0-only terms or buy a commercial license that Zitadel offers.
Team that needs a built-in record of every identity change over time	Zitadel	Keycloak fits if your audit needs are met by its logs and your own retention tooling, and you do not need event-level history.
Federation from LDAP or Active Directory and brokering to external OIDC or SAML providers	Keycloak	Zitadel fits when federation needs are narrow and the organization model matters more than directory integration breadth.
Kubernetes operation with an official operator and OLM-based installs	Keycloak	Zitadel fits if your platform team has already standardized on its Kubernetes deployment approach and can confirm it meets your needs.
Database standardization on an existing enterprise database such as Oracle or SQL Server	Keycloak	Zitadel fits if you can run PostgreSQL 14 to 18 and that database is acceptable to your DBA and compliance teams.
Small team that wants a long-established, widely documented identity provider with a broad community	Keycloak	Zitadel fits if you value its newer multi-tenant design and are prepared to confirm its roadmap and support options directly with the vendor.

How Keycloak and Zitadel are built and what that means for operations

Keycloak and Zitadel both sign users in over standard protocols, but they store state, scale their database and deploy to Kubernetes in different ways. The cards below cover the parts that shape day-two operations, so platform teams can test each one against their own hosting model before committing.

Protocol coverage and gaps

Keycloak supports OpenID Connect, OAuth 2.0 and SAML 2.0, brokers logins to external OpenID Connect or SAML providers, and federates users from LDAP or Active Directory. This matters when applications or partners still require SAML or directory-backed users. For Zitadel, confirm in its documentation and with DeployOpen's own test matrix which protocols, brokered identity providers and directory connectors your applications need, because the supplied facts do not list them in full.

Relational database as a hard dependency

Keycloak needs a relational database in production and supports PostgreSQL 14 to 18, MariaDB, MySQL, Microsoft SQL Server, Oracle Database and Amazon Aurora PostgreSQL. Its default dev-file database is not suitable for production. Teams that already run one of these engines can reuse existing backup, patching and high-availability practice, but they also inherit the database's licensing and upgrade schedule.

Event sourcing versus conventional state storage

Zitadel stores every change as an event, which gives a built-in audit trail of all changes over an unlimited period. Keycloak stores current state in its relational schema, so change history depends on the logging and auditing you configure. The trade-off for Zitadel is that event history grows with activity, so capacity planning and retention decisions belong in the design, not after go-live.

Kubernetes deployment through the Keycloak Operator

The Keycloak Operator is installed through the Operator Lifecycle Manager, which Keycloak recommends, or with kubectl, and it runs on Kubernetes and OpenShift. Platform teams should check how the operator upgrades Keycloak versions and how it fits their GitOps pipeline. For Zitadel, no supplied fact covers its Kubernetes deployment method, so ask Zitadel for its supported Helm chart or operator, upgrade path and recommended topology before comparing operating effort.

Self-hosted PostgreSQL requirement for Zitadel

Self-hosted Zitadel supports PostgreSQL 14 to 18, so the database is the one dependency you must provide and operate yourself. Confirm which PostgreSQL version your platform team is committed to, how backups and point-in-time recovery will be tested, and whether a managed PostgreSQL service is acceptable under your data residency rules. Zitadel's database configuration page is the place to verify supported connection and migration settings.

Feature comparison: protocols, database, audit trail and tenant model

This table compares Keycloak and Zitadel on the capabilities that most often decide a shortlist: license, protocols, brokering, directory federation, database, Kubernetes installation, audit design and tenant model. Where a row lacks a confirmed fact for one platform, the cell tells you what to confirm with the vendor. Use it to check fit against your own requirements, not as a complete feature inventory.

Capability	Keycloak	Zitadel
License	Apache-2.0 (Keycloak LICENSE file)	AGPL-3.0-only since Zitadel v3, with some directories under Apache-2.0 or MIT and a commercial license offered
Current release	Keycloak 26.8.1, released October 13, 2026	Zitadel v4.19.5, released October 15, 2026
Protocols	OpenID Connect, OAuth 2.0 and SAML 2.0	Confirm the full protocol list for your version in the Zitadel documentation before relying on SAML or other protocols
External identity brokering	Brokers logins to external OpenID Connect or SAML identity providers	Confirm brokering options for your required upstream providers with Zitadel
LDAP or Active Directory federation	Federates users from LDAP or Active Directory	Confirm directory federation support and configuration with Zitadel before you commit
Production database	Relational database required; PostgreSQL 14 to 18, MariaDB, MySQL, Microsoft SQL Server, Oracle Database and Amazon Aurora PostgreSQL	Self-hosted Zitadel supports PostgreSQL 14 to 18; confirm any other database options with the vendor
Kubernetes installation path	Keycloak Operator, installed through Operator Lifecycle Manager (recommended by Keycloak) or with kubectl	Confirm the supported Kubernetes deployment method and operator maturity for your target platform with Zitadel
Audit trail design	Confirm the admin event and audit configuration, retention and export options for your version	Event sourcing stores every change as an event, giving a built-in audit trail of all changes over an unlimited period
Organization or tenant model	Realms serve as separate identity spaces; confirm how your multi-customer model maps to realms in your design	Organizations act like SaaS tenants, with multiple organizations managed in one instance for customers who manage their own users

What each license requires when you embed identity in a product

Keycloak is licensed under *Apache-2.0*, a permissive license that lets you use, modify and distribute the software in commercial products. The current release is Keycloak 26.8.1, released on October 13, 2026, according to the Keycloak LICENSE file. Embedding Keycloak does not, by itself, require you to publish the source code of your own application.

Notice and attribution: Distributions generally need to keep the license text and copyright notices and identify the components you ship.
Modifications: If you change Keycloak source, you must mark your changes and keep the license terms with the modified files. Your own application code can remain proprietary.
Patent terms: Apache-2.0 includes an express patent license from contributors, which counsel will want reflected in your third-party review.
Bundled dependencies: Check the licenses of extensions, themes, custom providers and container base images, since they can carry different terms.
Operations: Licensing does not cover support. Confirm with your vendor or partner who patches the 26.8.1 line and how upgrades are handled.

Before release, ask counsel to confirm the notice and attribution steps for your distribution model, including whether you deliver containers, appliances or source to customers.

How database choice and Kubernetes operation shape the platform

Keycloak needs a relational database in production, and the supported list is wide: PostgreSQL 14 to 18, MariaDB, MySQL, Microsoft SQL Server, Oracle Database and Amazon Aurora PostgreSQL are all named in the Keycloak database guide. The bundled dev-file database is not suitable for production, so a pilot built on it cannot simply be promoted. If your organization already standardizes on Oracle or SQL Server, Keycloak can usually sit on the existing engine, and the database team should confirm the version and support matrix against the Keycloak database configuration guide before the design is locked.

Zitadel is narrower on this point. Self-hosted Zitadel supports PostgreSQL 14 to 18, so the database standard that matters is whether your platform team already runs PostgreSQL in that range with the backup, failover and patching practices you need. If your estate is built around SQL Server or Oracle, Zitadel adds a new engine to operate rather than reusing one. Ask the Zitadel team to confirm what a self-hosted deployment requires for replicas, connection handling and event storage growth, since an event-sourced store keeps every change and its size will grow over the life of the system.

For Kubernetes, the Keycloak Operator is installed through the Operator Lifecycle Manager, which Keycloak recommends, or with kubectl, so teams already running OLM on OpenShift or other clusters have a familiar path. Confirm which Keycloak versions the operator supports, how upgrades roll out and how your change window handles database migrations. For Zitadel, do not assume a packaging model: confirm with the vendor whether a supported Kubernetes deployment method exists, how it is versioned, and what the documented upgrade path is for a self-hosted instance before you commit to a cluster-based design.

What drives the running cost of each platform

Running cost for Keycloak or Zitadel comes from a small set of recurring components, each with its own owner and its own one-time setup. The cards below separate what you pay once from what recurs, and list what to ask for in a quote written from a fixed scope.

Infrastructure and database hosting

Both platforms run as stateful services that need a production database. Keycloak requires a relational database in production, and Zitadel self-hosted supports PostgreSQL 14 to 18, so the database becomes a shared cost line with its own backup, patching and high availability requirements. Ask the quote to state who provisions and operates the database, which instance sizes are assumed, and whether backup and restore testing is included. Hosting costs recur monthly, while the initial database design is one-time work.

Java and Go skills in the team

Keycloak is a Java platform and Zitadel is a Go platform, so the people who troubleshoot, extend and patch each one need different skills. Customizing Keycloak usually means Java extensions and provider code, while Zitadel customization is mostly configuration, its API and its event model. The one-time cost is training or hiring for the chosen stack. The recurring cost is the time senior engineers spend keeping that knowledge current. Ask the partner which skills the scope assumes and who will own the code after handover.

Upgrade and patch effort

Each platform moves on its own release cadence, and upgrade work recurs for the life of the product. Keycloak 26.8.1 is the current release, and Zitadel v4.19.5 is the current Zitadel release, so both need tested upgrade paths, staging environments and regression tests for any custom providers or event consumers. Zitadel's event-sourced data model adds migration checks that a simpler schema would not need. Ask for the number of upgrade cycles covered per year, the test scope for each cycle, and whether security patches are handled outside the planned upgrades.

Vendor and partner support

Community support is free for both projects, but production identity is rarely run on community channels alone. Keycloak and Zitadel each offer paid options through their own vendors, and DeployOpen offers fixed-scope implementation and retainers for ongoing support and upgrades. These are different contracts with different owners, so keep them separate in the budget. Ask what response expectations come with each support option, which versions they cover, and whether the partner's retainer includes upgrades and continuous testing or only incident response.

License and commercial terms

Keycloak is Apache-2.0, so the license itself carries no recurring fee. Zitadel moved to AGPL-3.0-only with v3, and a commercial license is offered as an alternative. If you distribute Zitadel inside a product or offer it as a network service, the AGPL terms and the cost of a commercial license must be priced before launch, not after. Ask legal counsel to review the AGPL obligations for your deployment model, and ask the vendor for written commercial terms, including what they cover and how they renew.

Moving from Keycloak to Zitadel or back: what transfers and what is rebuilt

This sequence turns a migration decision into a tested cutover plan, showing which identity objects can be moved, which must be rebuilt for a different tenant model, and how to prove the new platform works before users depend on it.

Inventory clients, realms and federation links
Start by listing every application that signs in against the source platform, every Keycloak realm or Zitadel organization and instance that holds users, and every external identity provider or user federation link (OpenID Connect, SAML, LDAP or Active Directory). Record the protocol, redirect URIs, token lifetimes, scopes and which team owns each application. The application owners confirm their list, and the identity engineer signs off a single inventory sheet. The step is done when every client has a named owner and a target decision: move, re-register or retire.
Map tenancy from realms to organizations
Decide how the source model maps onto the target. A Keycloak realm is usually the isolation boundary, while a Zitadel organization is the tenant unit inside one instance, so several realms may become several organizations, or a single realm may need restructuring. Document which roles, groups, branding and login policies are realm-wide and which are per customer. This mapping is the most consequential design artifact in the project. It is complete when the architecture owner approves a written tenant map that every later step follows.
Export users and confirm credential transfer
Extract user profiles, group memberships and attributes from the source, and check which credential material the target can import. Password hash transfer depends on the algorithm, the import format and the vendor's current tooling, so confirm the exact support for Keycloak and Zitadel with each vendor before planning a silent migration. Where hashes cannot move, plan a forced reset or a lazy migration path that verifies the old credential at first login. The step closes with a sample import in a test environment and a count reconciliation between source and target.
Rebuild claims, mappers and roles
Protocol mappers in Keycloak and the claim and action configuration in Zitadel do not translate one to one, so each token claim that applications depend on must be rebuilt and tested. Recreate role and group logic against the target's model, and check audience, scope and issuer values that resource servers validate. The identity engineer and each application owner run token comparison tests on the same test user. The step is complete when the decoded tokens from both platforms match on every claim the applications read.
Re-register applications and external brokers
Create the target clients or applications with the rebuilt redirect URIs, secrets and signing keys, then reconnect each external identity provider broker and any SAML metadata exchange. Keep the old and new client identifiers recorded side by side so rollback is possible. Because federation trust is set up on both sides, the partner or IT owner of each upstream provider must confirm the new endpoints. The step is done when a test login succeeds through every broker and every application in a non-production environment.
Run both platforms in parallel
Keep the source platform live while selected applications or a pilot group of users sign in through the target. Route a small, agreed population through the new platform, monitor failed logins, token errors and session behavior, and compare audit records across both systems. Operations staff should confirm that backups, monitoring and alerting cover the target, since it becomes a production dependency during this stage. The step produces a written list of defects with owners and a go or no-go decision for cutover.
Cut over and verify production sign-ins
Switch DNS, application configuration and broker endpoints to the target in an agreed change window, and keep the source read-only as the rollback path until the business owners accept the result. Verify sign-in, token issuance, logout and access for each critical application, then confirm that the audit trail on the target records the migration events. The step closes when the change record shows every application verified and the rollback window has ended.
Decommission the source and document
After the rollback window closes, retire the old realms or instance, revoke service accounts and secrets that existed only for the source, and update runbooks, disaster recovery plans and access reviews to name the new platform. Record the final tenant map, claim mappings and known gaps so that a later move back to Keycloak starts from the same evidence. The step is complete when the decommission record is signed and the documentation is stored with the identity team's change history.

What implementing each platform involves and where projects run long

Keycloak implementation work centers on realm design, which decides how users, clients, roles and login flows are separated. Teams typically map each product or customer boundary to a realm or a set of clients, then configure brokering to external OpenID Connect or SAML identity providers and federation from LDAP or Active Directory. Each federation link needs attribute mapping, sync scheduling and a decision on where passwords are validated. Customization covers themes and custom authenticators, which are code you will maintain through every upgrade. Hardening and backup follow: the production database must be a supported relational engine, and the runbook must cover database backups, realm export and restore, and the Operator configuration if you run on Kubernetes through the Keycloak Operator installation guide.

Zitadel implementation work starts with the organization model. Each customer tenant maps to an organization inside one instance, so you must decide how instance-level administrators, organization administrators and end-user roles divide responsibility before any application is onboarded. Application onboarding then repeats per tenant: each client needs its redirect URIs, grants and project roles created, usually through automation rather than the console. Event store operations are the part teams underestimate. Because every change is stored as an event, the PostgreSQL database grows with history, so the retention, backup, restore and capacity plan belongs in the design phase. Confirm with Zitadel which database and version your deployment requires before you commit to a hosting pattern.

Projects run long in three predictable places. Claim mapping is the first: tokens must carry the tenant, role and group attributes your applications expect, and each source system uses different attribute names. Tenant onboarding automation is the second, since a manual process that works for ten customers can break at several hundred. The third is integration with existing audit tooling, because Zitadel's event history must be exported, retained and queried in a form your SIEM and compliance team accept. Ask for each of these to be written into the statement of work with acceptance criteria. DeployOpen plans and scopes this work in writing before it starts, so the boundaries, deliverables and timelines are agreed up front.

Questions buyers ask before choosing or hiring help

What does a Keycloak or Zitadel implementation cost?

No supplied fact gives a price for either platform's implementation, and DeployOpen does not publish a price list. Both platforms are open source, so the license fee is zero, but the cost is labor: planning, configuration, database and Kubernetes setup, identity provider federation, hardening, backup, documentation and testing. The main drivers are the number of applications and realms or organizations, whether you need LDAP or Active Directory federation, the number of external identity providers to broker, your database choice, and how much custom login or branding work is involved. Ongoing costs include infrastructure, your staff time, upgrades and any support retainer. Quotes follow the written scope, so ask for line items by workstream, what is one-time and what recurs, and which assumptions about your environment the price depends on.

How long does an identity platform project take?

Duration depends on scope and on how quickly your team can provide access and decisions, not on the platform name alone. The biggest timeline drivers are the number of client applications to integrate, the depth of user migration or directory federation, approval cycles for the production database and Kubernetes environment, and whether your product needs tenant or organization onboarding flows. Most engagements are fixed-scope, so the agreed deliverables and timeline are written down before work starts. Ask for a phased plan with milestones for a proof of concept, a staging environment, a production cutover and handover, and confirm which items depend on your change windows.

What does the work require from our internal team?

Expect your team to supply several things regardless of who does the build. You need named owners for identity requirements, a decision maker for token lifetimes, role and claim design, and access to your cloud or data center accounts. Your database administrators need to approve and back up the production database, and your platform team needs to own the Kubernetes cluster or operator lifecycle after handover. Security and compliance staff should review the control mapping and evidence. Application owners must test their integrations in staging. Ask the provider to list these responsibilities by name in the written scope so gaps show up before the project starts.

Can our internal team deploy and run Keycloak or Zitadel without outside help?

Yes, many teams do, and both projects publish documentation for self-hosting. Keycloak needs a relational database in production and the Keycloak Operator can be installed through the Operator Lifecycle Manager or with kubectl. Zitadel's self-hosted setup also depends on PostgreSQL. The questions to answer honestly are whether your team has spare capacity to own upgrades, security patches, backups, testing of each release and incident response, and whether it has done OAuth and OpenID Connect integration at production scale before. Outside help is most often used for a fixed-scope first build, a hardening review, or a retainer for upgrades and testing, rather than for an open-ended handover.

Does Zitadel's AGPL license affect a SaaS product we sell?

It can, and the answer depends on how you use and distribute the software, so confirm it with your legal counsel. Zitadel moved from Apache-2.0 to AGPL-3.0-only with v3 in April 2025, and LICENSING.md notes that some directories are under other licenses and that a commercial license is offered. The AGPL is designed to reach network-accessible services, so modifications you make to Zitadel and offer to users over a network may carry source disclosure obligations. Keycloak is under Apache-2.0, which carries different obligations. Ask your counsel to review the exact Zitadel directories you would ship or modify, whether a commercial license is needed, and how your deployment model fits these terms before you commit.

How should we compare implementation quotes?

Compare quotes on scope, not on total price. Each quote should list the platform version, the deployment target, the database, the number of applications and identity providers, the federation sources, the customization and branding work, the testing approach, the documentation and handover, and what is excluded. Check whether the quote separates one-time build work from recurring upgrades, support and testing retainers, and whether it states assumptions about your environment. Ask each provider how they will handle a new major release, how they will document decisions, and who keeps operational knowledge after the project ends. A low quote with a narrow scope can cost more later if the excluded items are needed for production.

Does DeployOpen hand over the platform and the documentation at the end?

DeployOpen plans, implements, customizes, integrates, hardens, backs up, upgrades, documents and supports self-hosted open-source platforms inside your own infrastructure, so the deployment remains in your cloud accounts, data centers or air-gapped networks. Handover content, including documentation and runbooks, should be listed in the written scope before work starts. Ongoing support, upgrades and continuous testing are available as retainers. DeployOpen does not issue audit reports or certifications, so ask how compliance evidence will be prepared for your independent assessor.

How DeployOpen helps teams choose, implement or migrate

DeployOpen plans, implements, customizes, integrates, hardens and documents self-hosted open-source platforms inside the client's own infrastructure, so the Keycloak or Zitadel deployment runs in your cloud account, data center or air-gapped network. We start from the workload you need to identity-enable, then agree the written scope before any build work begins.

How we scope

Engagements are fixed-scope, with scope, deliverables and timelines agreed in writing before work starts.
We document which applications, login flows, external identity providers and user directories must work with the chosen platform.
We confirm the target database engine and version, since Keycloak and Zitadel both need a production relational database.

How we build

We deploy into your environment, using the Keycloak Operator or Zitadel's supported Kubernetes approach where your cluster standards call for it.
We configure tenant or realm structure, federation to LDAP or Active Directory, and brokering to external identity providers.
We test login, token, provisioning and audit behavior against your applications and record the results for your review.

How we hand over

You receive documentation covering configuration, runbooks, backup and restore steps, and upgrade procedures for your team.
We prepare the access, logging and change records that your internal or external assessors may ask to see.
Knowledge transfer sessions are scoped in the written agreement so your operators can run the platform without us.

How we support

Ongoing support, upgrades and continuous testing are available as retainers after handover.
Retainers can cover version upgrades to new Keycloak or Zitadel releases, after your team confirms licensing and compatibility impact.
Ask for the retainer terms, response expectations and upgrade scope in writing before you sign a quote.

Keycloak vs Zitadel