Keycloak vs Zitadel vs Ory: which to choose

Keycloak vs Zitadel vs Ory: which platform fits your customer-facing apps

If your customer-facing apps need hosted login pages, SAML and an admin console under Apache-2.0, Keycloak is the closest fit. If you are building a multi-tenant B2B product where each customer manages its own users and you want SCIM and an event-sourced audit trail, Zitadel is built for that shape, though its core, Console and hosted login are under AGPL-3.0. If your team wants a headless build with its own login UI, Ory's Apache-2.0 components are a strong base, but SAML, SCIM and organization login sit in the paid Ory Enterprise License builds, so budget for that before you design around them. The sections below test each claim against your login flows, tenant model and licensing obligations.

The first check is the protocol list your customers will require. Keycloak supports OpenID Connect, OAuth 2.0 and SAML 2.0 in its open source release, and it brokers logins to external OIDC or SAML providers. Zitadel implements OIDC, OAuth 2.0 and SAML 2.0 and provides a SCIM v2 service provider interface, and its organizations let each customer use a different identity provider. Ory Kratos has no SCIM, SAML or organization login in its open source version, so a B2B SSO requirement means pricing the Enterprise License with Ory before you commit. Confirm the exact feature list for your target edition with each vendor in writing.

Which platform fits which scenario

This table maps four common situations to the platform that fits best and the single fact that usually decides it. Read each row against your own requirements: if SAML or SCIM is mandatory on the product side, that row changes the answer for Ory.

Scenario	Best fit	The fact that decides it
B2B SaaS with customer-managed SSO	Zitadel or Keycloak	Zitadel offers instances and organizations with per-customer identity providers and SCIM v2 in the open source server, while Ory's SAML, SCIM and organization login need the Enterprise License, so confirm that licensing cost before choosing Ory.
Consumer apps with a custom login UI	Ory (open source components)	Ory Kratos is API-first and lets your team build its own login UI with passwords, passkeys, social sign-in and TOTP, whereas Keycloak and Zitadel provide hosted login pages that you style rather than replace.
Internal workforce SSO	Keycloak	Keycloak supports SAML 2.0 and OpenID Connect in the Apache-2.0 server, federates users from LDAP or Active Directory, and includes an admin console that most internal IT teams can run without custom code.
Existing Java or Kubernetes platform team	Keycloak	Keycloak is a Java server with a Kubernetes Operator installed through Operator Lifecycle Manager, so your platform team can reuse existing operational skills, while Zitadel's Helm-based deployment and Ory's headless services suit teams comfortable building their own surrounding components.

What the license and paid editions change for each platform

Keycloak is licensed under Apache-2.0, and the project's community releases carry that license without a separate enterprise build. The current release is 26.8.1, published October 13, 2026, and the project plans four minor releases a year. For most teams the license means you can run, modify and embed the server in your own products without a copyleft obligation to publish your changes. The main commercial question is support rather than features. Red Hat publishes the Red Hat build of Keycloak, a supported distribution based on the open source project that replaces Red Hat Single Sign-On.

Apache-2.0 for the server: You can run and modify the community distribution without a copyleft trigger, so internal patches do not force you to publish source.
Community releases without a vendor SLA: Upstream fixes ship with the project's release cadence, and you carry the upgrade and patch testing yourself or through a services partner.
Red Hat build as a supported option: Red Hat's distribution is a subscription product with vendor support. Its product page showed version 26.6 as the latest at the time of the source, so confirm the current version before you plan.
Support is a separate purchase: The license does not include a support contract, so budget for either a Red Hat subscription, a services retainer or in-house expertise.

Before you commit, confirm with Red Hat or your chosen support provider which artifacts, patches and support windows a subscription covers, and whether it changes the upgrade path you would follow.

How hosted login and headless UI differ in architecture

Keycloak and Zitadel each ship a finished login experience and an admin console, so a team gets a working sign-in page, account screens and administration tools on day one. Ory takes the opposite approach. Ory Kratos handles identities, Ory Hydra handles OAuth 2.0 and OpenID Connect, and Ory Keto handles permissions, all exposed through APIs. Your team builds and styles the login and registration screens, and it owns the glue between those services. Decide early whether your product team wants to design every login screen, or whether a hosted login page meets the brand and security requirements. That choice drives most of the front-end effort, and it is hard to reverse once customers are signing in.

On the database side, Keycloak requires 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 for development only. Zitadel uses PostgreSQL 14 to 18 for self-hosted deployments. Kratos supports SQLite, PostgreSQL, MySQL and CockroachDB. Check these lists against your standard database platform and your database operations skills before you commit. If your organization only runs Oracle or SQL Server, Keycloak is the only option of the three that fits without a new database engine. Confirm current support with each vendor's documentation, since database lists change across releases.

Zitadel stores every change as an event, which gives it a built-in audit trail of all changes over an unlimited period. That is valuable when auditors or customers ask who changed a role or an identity provider and when. The trade-off is storage: the event history grows with every change, so plan database capacity, backup size and retention policy from the start, and ask Zitadel how its event tables behave under your expected change volume. Keycloak and Ory do not present their storage as an event log in the same way, so an audit requirement should be checked against each product's logging and admin event features rather than assumed.

Multi-tenancy, SAML, SCIM and database support side by side

This table compares license, release, protocol, SCIM, multi-tenancy, database and deployment capabilities for Keycloak, Zitadel and the Ory stack. Read the Ory column as a conditional answer, because SAML, SCIM and organization login depend on which Ory edition you run. Confirm any Ory feature against your edition before you rely on it in a requirement.

Capability	Keycloak	Zitadel	Ory (Kratos, Hydra, Keto, Oathkeeper, Polis)
License	Apache-2.0 for the server	AGPL-3.0-only for core, Console and hosted login since v3; APIs, SDKs and Helm charts stay Apache-2.0	Apache-2.0 for open source components; Ory Enterprise License covers optimized builds with paid features
Current release (as supplied)	26.8.1, released October 13, 2026	v4.19.5, released October 15, 2026	Kratos and Hydra v26.2.0, both published March 20, 2026
OIDC, OAuth 2.0 and SAML 2.0	Yes: OpenID Connect, OAuth 2.0 and SAML 2.0 as server protocols	Yes: OpenID Connect, OAuth 2.0 and SAML 2.0, plus a device authorization grant	OIDC and OAuth 2.0 through Hydra; SAML single sign-on comes from Polis, which is a separate component to confirm in your build
SCIM availability	Confirm in your release and deployment; not listed in the facts supplied for this comparison	SCIM v2 service provider interface for user provisioning and lifecycle	SCIM sits with Ory Polis (directory sync); the Kratos README lists SCIM as an enterprise feature outside open source
Multi-tenancy model	Realms for isolation; Organizations feature for B2B grouping of users within a realm	Instances as virtual tenants with full data isolation, organizations inside instances, projects for apps and roles	Kratos multi-tenancy and organizations are listed as Enterprise License features; open source Kratos does not include them
Per-customer identity provider	Brokering to external OIDC or SAML providers; confirm per-organization setup for your version	Each customer organization can use a different identity provider	Organization login (SSO) is an enterprise feature per the Kratos README; confirm in your edition
Production database	Relational database required; PostgreSQL 14 to 18, MariaDB, MySQL, Microsoft SQL Server, Oracle, Aurora PostgreSQL, Azure SQL and others listed in the database guide	PostgreSQL 14 to 18 for self-hosted deployments	Kratos supports SQLite, PostgreSQL, MySQL and CockroachDB; confirm database support for Hydra, Keto and Polis separately
Hosted login versus headless UI	Built-in admin console and login pages, with theming	Hosted login included, with a Console for administration	Headless, API-first: teams build their own login UI on Kratos APIs
Self-hosted deployment options	Server distribution on virtual machines, Kubernetes Operator (installed with OLM or kubectl), experimental Helm chart	Linux and macOS binaries, Docker Compose and Kubernetes with the official Helm chart recommended for high availability	Self-hosted open source components plus Enterprise License builds; Ory Network is the managed option alongside them

How each platform models tenants for B2B customers

Each platform separates customers at a different level, and that choice shapes data isolation, customer self-service and licensing. The four cards show which model fits your tenant count, your isolation rules and whether customers bring their own identity provider.

Keycloak realms and Organizations

A Keycloak realm is a separate namespace with its own users, clients, roles and login settings, so one realm per customer gives the clearest separation of identity data. The Organizations feature groups users by customer inside a realm, but confirm its current scope before treating it as full isolation. Choose realms when each customer needs its own login policy, branding or identity provider configuration, and ask your Keycloak partner or test environment how many realms your database and admin workload can carry.

Zitadel instances and organizations

Zitadel separates tenants at two levels. An instance is a virtual tenant with full data isolation, and organizations inside an instance hold the projects and users for each customer. Each organization can use a different identity provider, such as Entra ID, Okta or any OIDC or SAML source, so a customer's staff sign in with their corporate account. Choose this model when customers manage their own users or bring their own identity provider, and confirm whether one instance per region or per business unit fits your data residency plan.

Ory Kratos multi-tenancy in Enterprise builds

The Kratos README lists SCIM, SAML, organization login and CAPTCHAs as enterprise features absent from the open source version. Kratos multi-tenancy and organizations sit behind the Ory Enterprise License, which Ory describes as optimized builds of the same servers and drop-in replacements for open source installs. If you plan B2B tenancy on Ory, include the Enterprise License in the design from the start and ask Ory which tenancy features are covered at the support tier you need.

Admin delegation to customers

Delegation decides whether a customer administrator can create users, reset passwords or assign roles without seeing other tenants. Zitadel's organization model is documented for B2B products whose customers manage their own users. For Keycloak, confirm how delegated admin roles behave in your release, and for Ory, expect your team to build the customer admin screens on the headless APIs. Test cross-tenant access in every option: a customer admin in tenant A must fail when reading tenant B's users.

What drives the running cost of each identity platform

The running cost of Keycloak, Zitadel and Ory is set less by the license fee, which is zero for the Apache-2.0 open source Keycloak and Ory Open Source builds, than by who carries the work after go-live. For each platform, list the cost lines separately: compute and storage for the server nodes, the database service and its backups, your staff time for upgrades and CVE response, and any subscription you buy. Keycloak and Ory Open Source are free to download, but someone on your side or a services partner is paid to operate them. Zitadel's AGPL-3.0 core and its commercial license are a separate question for legal review, since a commercial license is a contract with a recurring cost. Ask each vendor in writing which features sit behind a paid tier and which support terms come with it.

Separate the one-time work from the recurring work. Implementation covers the initial design, the database and high availability build, realm or organization modeling, and identity provider connections. That work is paid once, under a written scope. Recurring cost comes from upgrades and CVE response. Keycloak ships four minor releases a year under its current plan, and its Operator documentation strongly recommends manual approval mode for operator updates to avoid unintended automatic upgrades. That recommendation means someone must test and approve each change, so budget that staff time every cycle. Ory is more explicit about the trade-off: its open source components suit deployments where occasional upgrade downtime is acceptable and guaranteed CVE patching is not required. If your customer-facing login must not go down for upgrades or wait on a patch, the Ory Enterprise License sits in the recurring budget, and the Ory Enterprise License documentation describes its support SLAs and timely CVE patches.

Database operations are the cost most often underestimated. All three platforms need a production relational database: PostgreSQL 14 to 18 for Keycloak and Zitadel, and PostgreSQL, MySQL, CockroachDB or SQLite for Ory Kratos, with SQLite fit only for development. Keycloak's high availability designs need a synchronously replicated database, so a managed database service or a DBA team becomes a recurring line item. Keycloak also migrates its schema automatically at startup by default, and the upgrading guide suggests manual migration for large deployments, which adds a runbook step. Ask your vendor or partner to quote backup, restore testing and monitoring of the database as separate items, and confirm whether any Zitadel or Ory feature in your shortlist requires an enterprise build before you price the run state.

Running cost drivers for Keycloak, Zitadel and Ory

Recurring cost in self-hosted identity comes from the components you keep running, the database you must keep highly available, and the license tier that unlocks features you need in production. The three cards below cover one driver per platform, with the points to raise in a quote before you commit.

Keycloak high availability and database

Keycloak's production high availability designs both need a synchronously replicated database, so the database tier is usually the largest recurring line. The single-cluster design can span availability zones, while multi-cluster v2 links independent sites without an external Infinispan cluster. Ask whether the quote covers the database platform, its replication and its backups, and whether the Keycloak Operator upgrade approach is set to manual approval. Upstream Keycloak carries no license fee, so recurring spend is infrastructure, staff time and any support contract you choose.

Zitadel PostgreSQL and Helm footprint

Self-hosted Zitadel depends on PostgreSQL, with versions 14 through 18 supported, and the official documentation recommends Kubernetes with the Helm chart for high availability. Recurring cost therefore follows the PostgreSQL service, the cluster capacity and the operator time to maintain both. Because Zitadel v3 moved its core, Console and hosted login to AGPL-3.0, check with counsel whether your modifications or embedding trigger source obligations, and ask whether a commercial license quote is needed to avoid that obligation. Price any commercial license against the scope you actually need.

Ory paid builds and component count

Ory splits identity into separate services: Kratos for identities, Hydra for OAuth2 and OpenID Connect, Keto for permissions, Oathkeeper for the access proxy and Polis for SAML, OIDC single sign-on and SCIM sync. Each service is a deployment you patch, monitor and back up. SAML, SCIM and organization login sit in the Ory Enterprise License, which is a recurring subscription for production B2B single sign-on. Ask which components the quote covers, whether OEL builds are drop-in replacements for your open source install, and what the 24/7 support and CVE patch terms cover.

How implementing each platform typically proceeds

The sequence below takes a team from requirements to a tested, upgradable customer-facing identity service, and shows where Keycloak, Zitadel and Ory need different work at each stage.

Confirm tenancy and protocol requirements
Before any installation, the architecture owner, security lead and product owner write down how customers are separated (one realm or instance per customer, or shared users across organizations), which protocols each application needs (OIDC, OAuth 2.0, SAML 2.0), and whether SCIM provisioning is required. This is where the platforms first diverge: Keycloak models tenants as realms and organizations, Zitadel uses instances and organizations, and Ory needs SAML, SCIM and organization login from its Enterprise License builds. The step is done when the requirements are signed off and each gap is marked as covered by the open source build, the paid build or custom work.
Choose the edition and confirm the license terms
Legal and procurement review the license for each candidate: Apache-2.0 for Keycloak, AGPL-3.0 for the Zitadel core with its Apache-2.0 client and API directories, and Apache-2.0 for the Ory open source components alongside the Ory Enterprise License. The team decides whether it needs a paid build, a vendor subscription or only the community release, and whether modifying or offering the server to users triggers source obligations. The output is a short written decision record naming the edition, the license obligations and the support model.
Stand up the database and high availability
Platform engineering provisions a supported production database. Keycloak needs a relational database such as PostgreSQL, and its high availability designs require a synchronously replicated database. Self-hosted Zitadel uses PostgreSQL 14 to 18. Ory Kratos supports SQLite, PostgreSQL, MySQL and CockroachDB, and the team should choose a production-grade option. Each platform's deployment path differs: Keycloak can run on Kubernetes through its Operator or on virtual machines, Zitadel recommends Kubernetes with its Helm chart for high availability, and Ory is typically assembled from several services. The step closes when a failover test shows the cluster surviving the loss of one node and the database backup restores into a clean environment.
Configure identity brokering and directory connections
The team connects customer and workforce identity sources. Keycloak brokers logins to external OIDC or SAML providers and federates users from LDAP or Active Directory. Zitadel lets each customer organization use a different identity provider, including Entra ID, Okta, LDAP and any OIDC-compliant provider. With Ory, SSO connections and directory sync depend on the Enterprise License features, so the team confirms those with Ory before design. The output is a tested login for one test identity from each source, with the claims mapped to the application roles.
Set up provisioning and SCIM
Where customers' identity teams expect automated user lifecycle management, the team configures SCIM. Zitadel provides a SCIM v2 service provider interface. Keycloak SCIM support and Ory's SCIM capability (through Polis or the Enterprise License) should be confirmed against the exact version under evaluation, since they are implemented differently. The team tests create, update and deactivate events against a sample customer tenant, and verifies that deprovisioning revokes active sessions. The check is a documented test run with the outcome recorded for each lifecycle event.
Build or customize the login experience
This is the largest difference between the platforms. Keycloak and Zitadel ship a hosted login that can be themed and extended, which suits teams that want a managed sign-in page. Ory Kratos is API-first, so the team builds its own login and registration UI against the APIs, which adds front-end and security engineering work and gives full control over the flow. The team also configures passwords, passkeys and multi-factor authentication. Zitadel documents passkeys with password fallback, and Kratos supports TOTP and passkeys. The step closes when the login flows pass a security review and accessibility checks for the customer-facing screens.
Run upgrades, backups and security testing
Operations sets up a regular upgrade cadence, tested backups and monitoring. Keycloak plans four minor releases a year and recommends manual approval mode for Operator updates, and its database schema migrates automatically at startup by default, so teams often test upgrades against a copy of production first. Zitadel and Ory releases need the same staging test. A security firm then tests the login flows, token handling, tenant isolation and API authorization, and the findings feed back into the configuration. Done means a dated upgrade runbook, a restore test on record and a retest of any critical or high findings.

Common questions before choosing or hiring help

How much more effort does Ory headless need compared with Keycloak?

Ory needs more application work, and Keycloak needs more platform configuration. Keycloak ships an admin console, login pages, realms and a user store, so a team can run a working SSO service before writing login code. Ory Kratos, Hydra and Keto are API-first components: your team builds the login and registration screens, the consent flow and the authorization model on top of them. Effort drivers include how many applications need custom login journeys, whether your front-end team owns the login UI, and whether you need a permission model such as the one Ory Keto provides. Ask any vendor or partner to split the estimate into server configuration, UI build, integration and testing, because those four lines move in different directions.

Do SAML and SCIM require a paid Ory build?

Yes, according to the Ory Kratos README, SCIM, SAML, organization login (SSO) and CAPTCHAs are enterprise features that are not part of the open source version. Ory Polis, which handles SAML and OIDC single sign-on with SCIM directory sync, is also Apache-2.0, but the enterprise feature set for Kratos is what changes the picture for B2B SSO. The Ory Enterprise License covers optimized builds of the same servers, plus multi-tenancy and organizations, 24/7 support SLAs and timely CVE patches. Confirm with Ory which components, builds and support tiers your use case needs, and get the license terms in writing before you design around them. By contrast, Keycloak and Zitadel both document SAML 2.0 and Zitadel documents SCIM v2 in its open source distribution, so the comparison is about your B2B requirements, not protocol support alone.

Does Zitadel's AGPL-3.0 license affect a SaaS product?

It can, and the answer depends on whether you modify Zitadel and how you expose it to users. Zitadel moved its core, Console and hosted login from Apache 2.0 to AGPL-3.0 with v3.0 on 31 March 2025, according to the Zitadel blog. The AGPL network clause matters when you change the Zitadel source and offer it to users over a network, because you may have to offer those changes under the same license. APIs, SDKs, proto definitions, examples, documentation, Helm charts and Terraform configurations remain Apache 2.0. Using an unmodified Zitadel server and calling its APIs from your product is a different situation from embedding or patching the server. Have your legal counsel review the obligations, and ask Zitadel about its commercial license terms if you need to avoid AGPL obligations.

How long does a migration between Keycloak, Zitadel and Ory take?

No supplied fact gives a duration, so the timeline depends on the work, not on a standard figure. The main drivers are the number of users and credential types to move, whether password hashes can be migrated or users must reset them, how many applications and client registrations must be re-pointed, and how much custom login code depends on the old platform's APIs. Zitadel documents migration guides from Keycloak and other systems, using approaches such as just-in-time migration, which can reduce a bulk cutover. Ory's headless model means login screens and session logic usually move with the application code, which can add work. Ask any partner for a written migration plan that lists each application, identity source, credential type and cutover window before agreeing to a timeline.

What skills does our team need to run any of these platforms?

At minimum you need people who can operate a relational database, manage TLS certificates, run containers or Kubernetes, and read OIDC and SAML configuration. Keycloak needs a production database from its supported list, and it recommends the Keycloak Operator with Operator Lifecycle Manager on Kubernetes or OpenShift, with manual approval for operator updates. Zitadel self-hosting uses PostgreSQL 14 to 18, and the official Helm chart is the recommended path for high availability. Ory components use SQLite, PostgreSQL, MySQL or CockroachDB for storage, and the team also needs front-end and back-end engineers to build login flows. Map these skills against your staff before choosing, and confirm the exact support matrix with each vendor.

Is an outside implementation partner worth it for this decision?

It is worth considering when your team lacks identity, database or Kubernetes experience, or when a migration must run alongside production logins. DeployOpen plans, implements, customizes, integrates, hardens, backs up, upgrades and documents self-hosted open-source platforms inside your own infrastructure, and most engagements are fixed-scope with scope, deliverables and timelines agreed in writing before work starts. DeployOpen does not publish a price list, so a quote follows from the written scope. Ask any partner which platform they recommend and why, what they will hand over, who owns the database and keys after go-live, and whether ongoing support is a separate retainer. A partner should not be your only source of evaluation: test each shortlisted platform against your own requirements first.

Which platform should we pick if SAML is a hard requirement?

Keycloak and Zitadel both document SAML 2.0 in their standard distributions, so either can be a starting point for enterprise SSO. Keycloak also brokers logins to external OIDC or SAML providers and federates users from LDAP or Active Directory. Zitadel federates login from providers including Entra ID and Okta over OIDC or SAML, and each customer organization can use a different identity provider. For Ory, SAML sits in the paid Enterprise License builds, so budget for that before committing. Test your specific identity providers, signing requirements and attribute mappings in a proof of concept, and confirm each platform's SAML feature list against its current documentation.

How DeployOpen helps choose and implement the platform

DeployOpen plans, implements, integrates, hardens, documents and supports self-hosted open-source platforms inside your own cloud accounts, data centers or air-gapped networks. For Keycloak vs Zitadel vs Ory, we start from the customer-facing requirements that decide the choice, then carry the chosen platform through to a documented, supported deployment.

How we scope

We confirm which customer-facing use cases, tenant model and login flows the platform must serve before comparing options.
Scope covers whether SAML, SCIM and organization login are needed, and whether they would require a paid Ory Enterprise License build.
Engagements are fixed-scope, with scope, deliverables and timelines agreed in writing before any work starts.

How we build

We deploy the selected platform in your environment, with the database, licensing choice and high availability design agreed up front.
For Zitadel, we confirm how AGPL-3.0 obligations apply to your modifications and embedding before any customization begins.
Integration, hardening and security testing of login flows and APIs are scoped and carried out against the written plan.

How we hand over

Deliverables include documented configuration, tenant and identity provider setup, backup and upgrade procedures for your team.
We prepare systems, controls and evidence for compliance assessments, while independent auditors issue any attestation or certification.
Handover includes a walkthrough so your engineers can operate the platform, with the decision record for the chosen option kept on file.

How we support

Ongoing support, upgrades and continuous testing are available as retainers after handover, scoped to your running platform.
Retainers can cover upgrade planning for the platform's release cycle, including checks before moving to a new minor or major version.
We can revisit the choice if licensing, edition or hosting requirements change, with the scope of that work agreed in writing.

Keycloak vs Zitadel vs Ory