Keycloak vs Logto vs Zitadel: which one fits your situation
A team adding login to a SaaS product that sells to other businesses should start with Zitadel or Keycloak, depending on how much they value organization-level tenancy and an event-sourced audit trail against a realm model with a long track record in enterprise SSO. A team building consumer sign-in with a modern developer experience should look first at Logto, whose repository is MPL-2.0 and which lists OIDC, OAuth 2.1, SAML and organizations in its feature set. A team consolidating internal SSO for employees and legacy applications usually fits Keycloak best, because its Apache-2.0 license, SAML 2.0 support and LDAP or Active Directory federation match that job closely. The choice depends on license terms, tenancy model and the operating skills your team already has, not on any single feature. Each platform's license, tenancy model and database requirements shape the work long after the first login flow works.
Before you commit, confirm the license obligations that apply to your build, since Zitadel's AGPL-3.0 core and Logto's MPL-2.0 terms differ from Keycloak's Apache-2.0 in what you must publish when you modify or embed the server. Check that each candidate supports the protocols your customers' identity providers require, including SAML and SCIM where enterprise buyers ask for them, and confirm in writing which features are included in the community build and which need a paid edition or Logto Cloud. Run a short proof of concept with one real tenant model, and have someone on your team who will own upgrades and database operations try the install before the decision is final.
Which platform fits B2B SaaS, consumer apps and internal SSO
This table maps four common scenarios to the platform that fits each one best, and names the condition under which that fit holds. Read each row as a starting point: confirm the condition against your own licensing, hosting and staffing constraints before you commit, and check the alternative column for the case where another platform would serve you better.
| Scenario | Best fit and why | When another platform is the better choice |
|---|---|---|
| B2B SaaS with customer-managed identity providers | Zitadel, if you want multiple organizations inside one instance, per-customer identity providers and customer admin delegation as first-class concepts. Its organizations map closely to tenants, and each customer organization can use a different identity provider. | Keycloak if your team already runs it and can model customers as realms or use its Organizations feature. Logto if you want a managed cloud and a Node.js stack, and can accept a single admin account on self-hosted OSS. |
| Consumer apps with passwordless and social login | Logto, for teams that want a developer-oriented login experience with social sign-in and a hosted or managed option. Zitadel also supports passkeys with password fallback, so it fits when the AGPL-3.0 license is acceptable. | Keycloak when consumer login must sit alongside deep SAML or LDAP integration, or when your team already operates Keycloak and does not want a second identity stack. |
| Internal workforce SSO for legacy and modern apps | Keycloak, because it combines SAML 2.0, OpenID Connect, LDAP or Active Directory user federation and an admin console under Apache-2.0. It is the most direct fit when legacy SAML applications and directory federation are in scope. | Zitadel or Logto if the estate is mostly modern OIDC applications and you do not need LDAP or Active Directory federation. Keycloak also needs a production relational database and synchronous replication for high availability designs, so confirm you can run that. |
| Small team with no platform engineers | Logto Cloud, if a managed service is acceptable and the goal is to avoid operating an identity server. Self-hosted Logto OSS needs Node.js and PostgreSQL, and its docs point to Logto Cloud for official support. | Keycloak or Zitadel only if you have or buy operations skills for a production database, upgrades and high availability. Confirm with each vendor the support and operating model you will get before you choose a self-hosted path. |
How Keycloak, Logto and Zitadel license their cores and paid options
Keycloak's core is released under Apache-2.0, a permissive license that lets you run, modify and embed the server without a copyleft requirement to publish your changes. Keycloak is a Cloud Native Computing Foundation incubating project, and the code you deploy is the upstream code from the public repository. Paid support comes from a separate route: the Red Hat build of Keycloak, Red Hat's supported distribution based on the open source project, which replaces Red Hat Single Sign-On.
- Modification duties: Apache-2.0 asks you to keep copyright and license notices and to mark changed files, but it does not require you to publish your changes to users or the public.
- Hosting for your own users: The license text itself does not create a source-disclosure duty when you run a modified server for your own staff or customers.
- Red Hat subscription: The Red Hat build is sold as a subscription, so its support terms are a contract separate from the Apache-2.0 grant.
- Version alignment: The community project ships on its own cadence, so a supported distribution can lag upstream. Confirm which Keycloak versions Red Hat covers before you plan against them.
Ask counsel to confirm that your notice handling and bundled third-party components fit your distribution model, and ask Red Hat which build and versions its subscription covers.
Logto's repository is licensed under MPL-2.0, a file-level copyleft license. Changes you make to MPL-2.0 covered files must remain under that license when you distribute them, while separate files in your own code can use other terms. Self-hosted Logto OSS is the free route, and its administrator model is the decision point for teams that need several people to manage the service.
- File-level copyleft: Modified MPL-2.0 files carry the duty to make those files available under the same license when you distribute the software. Confirm with counsel whether internal hosting for your own staff counts as distribution in your case.
- Single administrator by default: Self-hosted OSS supports only one administrator account by default, and adding more admin members requires a self-hosted license.
- Team management in Cloud: Logto Cloud includes team management, so the administrator model on the managed service differs from self-hosted OSS.
- Support route: Logto's documentation recommends Logto Cloud for official support rather than self-hosting on third-party providers, which affects who can support your deployment.
Ask Logto for its current self-hosted license terms in writing, and confirm whether the administrator limit changes the staffing model you need. The Logto OSS getting started guide lists the deployment requirements.
Zitadel moved its core, Console and hosted login from Apache 2.0 to AGPL-3.0 with v3.0 on 31 March 2025. Its APIs, SDKs, proto definitions, examples, documentation, Helm charts and Terraform configurations remain Apache 2.0, and the project offers a commercial license. The AGPL reaches software that users interact with over a network, so it carries the strongest obligations of the three platforms when you change the core.
- Network clause: If you modify the AGPL-3.0-only core and users interact with it over a network, you generally must offer those users the source of your modified version.
- Apache-2.0 integration parts: Building against the APIs, SDKs and Helm charts falls under Apache-2.0, which carries lighter notice requirements.
- Commercial license: The offered commercial license is the route for teams whose internal policy rules out AGPL obligations. Its terms come from Zitadel and must be requested directly.
- Version boundary: The relicensing applies from v3 onward, so earlier releases carry different terms. Confirm which version you plan to deploy.
Read the Zitadel LICENSING.md file and take your specific modification and hosting scenario to counsel before you rely on the AGPL position.
Side-by-side capabilities: protocols, SAML, SCIM and databases
This table compares license, release, protocol support, tenancy, brokering, passkeys, production databases, self-hosting and managed options for Keycloak, Logto and Zitadel. Where a cell says to confirm, the supplied research did not settle the point, so check it with the vendor before you shortlist. The main takeaway: SAML and SCIM coverage differs most across the three, so verify those rows against your integration list first.
| Capability | Keycloak | Logto | Zitadel |
|---|---|---|---|
| License | Apache-2.0 | MPL-2.0 | AGPL-3.0-only for core and Console since v3; APIs, SDKs and Helm charts remain Apache-2.0 |
| Current release | 26.8.1 (October 13, 2026) | v1.45.0 (October 13, 2026) | v4.19.5 (October 15, 2026) |
| OIDC and OAuth support | OpenID Connect and OAuth 2.0 supported | OpenID Connect and OAuth 2.1 stated as fully supported | OpenID Connect and OAuth 2.0 implemented, with a device authorization grant |
| SAML | SAML 2.0 supported for applications and brokering | SAML stated as fully supported; confirm the enterprise SSO scope with the vendor | SAML 2.0 implemented; confirm the features covered for your use case |
| SCIM | Not covered by supplied facts; confirm with the vendor | Not covered by supplied facts; confirm with the vendor | SCIM v2 service provider interface for user provisioning and lifecycle |
| Organizations or tenancy | Realms, plus an Organizations feature; confirm fit for B2B tenants | Multi-tenancy, enterprise SSO and organizations with organization RBAC and just-in-time provisioning | Instances as isolated virtual tenants, with organizations inside each instance |
| Identity brokering to external providers | Brokers logins to external OIDC or SAML providers and federates LDAP or Active Directory | Enterprise SSO is listed; confirm supported upstream providers with the vendor | Google, GitHub, Entra ID, Okta, LDAP, Keycloak and any OIDC-compliant provider, with a different provider per organization |
| Passkeys | Confirm the WebAuthn configuration in your version with the vendor | Not covered by supplied facts; confirm with the vendor | FIDO2 and WebAuthn passkeys with fallback to password login |
| Production database | PostgreSQL 14 to 18, MariaDB, MySQL, SQL Server, Oracle, Aurora PostgreSQL; dev-file database is for development only | PostgreSQL 14 or later (^14.0), with Node.js ^22.14.0 required | PostgreSQL 14 to 18 |
| Self-hosting options | Server distribution, Kubernetes Operator and Red Hat build as a supported distribution | Self-hosted OSS with a Docker image; the vendor warns against its Compose file in production | Linux and macOS binaries, Docker Compose and Kubernetes with the official Helm chart |
| Managed cloud | Confirm managed hosting options with a third party or Red Hat before planning | Logto Cloud, the vendor's managed service, which the docs recommend for official support | Zitadel Cloud, with pricing published on the vendor's pricing page; confirm plan limits there |
How each platform models tenants for B2B products
Zitadel models tenants as instances, organizations and projects. An instance is a virtual tenant with full data isolation, so customers who must never share user data can be given separate instances. Inside an instance, each customer is an organization where its users and projects live, and projects group applications, roles and grants. Zitadel's documentation states that each customer organization can use a different identity provider, which matters when one customer wants its own Entra ID tenant and another wants Okta or a SAML provider. Check whether your customers need full isolation (an instance per customer) or logical separation (organizations within one instance), because that choice drives how many instances you operate and how upgrades and backups are scheduled.
Logto models tenants as organizations with organization RBAC. Logto's README lists multi-tenancy, enterprise SSO and RBAC, and describes organizations that support organization-level roles, member invitations and just-in-time provisioning. This suits a SaaS product where each customer's admins invite their own staff and assign roles inside that customer's organization. Confirm in the current Logto documentation how organization roles, invitations and per-organization SSO connectors are configured, and test a cross-tenant access attempt before you rely on the model. Also confirm which of these features are available in self-hosted Logto OSS and which need a license or Logto Cloud, since self-hosted OSS limits administrator accounts by default.
Keycloak models tenants as realms, and its Organizations feature must be confirmed for your target version. A Keycloak realm holds its own users, clients, roles and identity providers, so each customer can be separated into a realm with strong isolation, at the cost of running and configuring many realms. Keycloak also offers an Organizations feature for grouping B2B members, but its scope and capabilities change between releases, so check the server administration guide for the version you plan to deploy. Before committing, ask three questions of every platform: can a customer administrator manage only their own users and applications, how is their data separated from other tenants in storage and backups, and who operates per-tenant configuration as the number of customers grows.
What drives the running cost of each platform
Licence fees are often the smallest line in a self-hosted identity budget. The larger costs come from the database, the high availability design, the upgrade cadence, the skills your team already has, and whether you buy support or a managed service. The cards below set out what is one-time, what recurs, and what to ask for in a written quote.
Database operation
Keycloak needs a relational database in production, and its supported list includes PostgreSQL 14 to 18, MariaDB, MySQL, Microsoft SQL Server, Oracle Database and Amazon Aurora PostgreSQL. Zitadel uses PostgreSQL 14 to 18, and Logto OSS requires PostgreSQL ^14.0. The database is often already run by a platform team, so the recurring cost is usually the time to back it up, patch it and restore it. Ask the partner who operates the database, what backup and restore testing is included, and whether a managed database service is priced separately.
High availability design
Keycloak documents three high availability architectures, and both supported designs need a synchronously replicated database. A single cluster spread across availability zones needs low-latency links between sites. Multi-cluster v2 avoids an external Infinispan cluster but adds sites to operate. Zitadel recommends Kubernetes with the official Helm chart for high availability, and Logto's published minimums describe a single node, so any multi-node design is extra work. One-time design and load testing are followed by recurring capacity and failover drills. Ask for the sizing assumptions and the tested failover behavior in writing.
Upgrade effort
Keycloak plans four minor releases a year and says breaking changes in a minor release will be opt-in. Keycloak also migrates its database schema at startup by default, but administrators can apply the SQL themselves, which the upgrading guide suggests for large deployments. The Keycloak Operator documentation strongly recommends manual approval mode for updates. Zitadel and Logto each ship on their own release cadence, so the cost is the recurring test cycle for whichever one you run. Ask the partner how many upgrades per year the retainer covers and who tests schema changes before production.
Staff skills
Keycloak is a Java server, and large clusters bring in Infinispan for session and cache handling, so you need Java and cluster operations experience. Logto is a Node.js application with a PostgreSQL backend, which suits teams already running JavaScript services. Zitadel stores every change as an event, so operators and auditors must understand event-sourced storage to read its audit trail and plan backups. Ask which of these skills the partner brings, and which you must hire or train for after handover.
Paid support and licenses
Keycloak, Zitadel and Logto OSS are open source, so the software itself carries no licence fee. Zitadel's AGPL-3.0 core has a commercial licence option, which matters if you modify or embed the server and do not want AGPL obligations. Logto OSS limits self-hosted deployments to one administrator account unless you buy a self-hosted licence, and Red Hat build of Keycloak is sold through a subscription. These fees recur annually. Ask the vendor for the exact list of paid features your use case needs, the support hours included, and the term of any commercial licence.
Managed cloud or self-hosted
Logto Cloud and Zitadel Cloud remove database and upgrade work from your team, and their recurring fees replace your own infrastructure and staffing. Self-hosting keeps data in your accounts or data center, which matters for regulated customers, but moves those costs onto your team. Logto recommends Logto Cloud for official support rather than self-hosting on third-party providers. Ask for a side-by-side estimate covering hosting, database, backup, on-call coverage and tenant growth, and check where customer data is held under each option.
What a Keycloak, Logto or Zitadel implementation involves
The sequence below takes a team from license and support decisions to a tested, documented identity service that its own operators can upgrade. Each phase names who does the work and whether it is fixed-scope or retained, so the quote maps to a written plan.
Confirm license and support requirements
Start by deciding which license obligations and support paths your organization accepts: Keycloak under Apache-2.0, Logto under MPL-2.0, or Zitadel's AGPL-3.0 core with its Apache-2.0 client and API directories. Legal or procurement review usually owns this, with the platform team supplying the facts on modification and embedding. Ask the vendor which support contract covers the distribution you will run, since Logto's docs point to Logto Cloud for official support. The step is done when the license position and support path are written into the scope document.
Choose the tenancy model
Decide how customers and internal business units map onto the platform before anything is installed. Zitadel uses instances, organizations and projects, with each organization able to use its own identity provider. Logto uses organizations with organization RBAC, and self-hosted Logto OSS allows only one administrator account by default. Keycloak uses realms and its Organizations feature. The customer team and the DeployOpen architect agree the model in a short design record, and changing it later is the costliest decision in this sequence.
Size and deploy the database and runtime
Select the database and runtime for the chosen platform. Keycloak needs a relational database in production, with PostgreSQL 14 to 18 among its supported options, and its dev-file database must not be used. Zitadel and Logto OSS both run on PostgreSQL, with Zitadel supporting versions 14 through 18 and Logto requiring PostgreSQL 14 or later with Node.js 22.14 or later. For high availability, Keycloak's documented designs need a synchronously replicated database. Deployment is fixed-scope work for DeployOpen, and the client's cloud or data center team keeps ongoing operation. The check is a successful failover test of the database and a documented connection path.
Configure brokering, SAML and SCIM
Connect the platform to the identity sources and applications that matter. This covers brokering logins to upstream OIDC or SAML providers, LDAP or Active Directory federation where it applies, and SCIM provisioning where a customer or HR system pushes accounts. Zitadel documents SCIM v2 and federation with several upstream providers, and Logto states SAML and just-in-time provisioning support, so confirm each protocol and feature against the version you deploy. DeployOpen configures these within the agreed scope, and the client supplies test accounts and application owners. The step closes when a test login succeeds for each identity source and a test deprovisioning event removes access.
Migrate users and clients
Move existing accounts and application registrations in a planned cutover. Zitadel publishes migration guides from Auth0, Keycloak, Firebase and another Zitadel instance, including just-in-time migration, so check whether your source system is covered before assuming a path. Keycloak and Logto migrations depend on the source platform and its password hashing and export options, which the team should confirm during discovery. Passwords and MFA enrollments often need a dedicated approach, and the client owns the decision on user communication. The step is done when user counts reconcile between source and target and a sample of users has signed in successfully.
Harden and test
Apply the hardening baseline agreed in scope, including TLS, administrative access controls, logging and metrics, backup and restore of the database, and the MFA or passkey policy. Zitadel supports passkeys with password fallback and Keycloak exposes metrics for monitoring, so include those in the test plan. DeployOpen runs the security testing included in scope and reports findings, while the client's security team signs off on residual risk. Note that DeployOpen prepares evidence for compliance assessments but does not issue audit reports or certifications. The step closes with a restore test from backup and a closed findings list.
Operate and upgrade
Hand over runbooks and move into operations, which is where most recurring cost sits. Keycloak plans four minor releases a year and says breaking changes in minor releases are opt-in, but its Operator documentation recommends manual approval for updates, so the upgrade procedure should reflect that. Logto and Zitadel release on their own cadences, and the team should track their release notes before each change. Retained work includes patching, monitoring, certificate renewal and upgrade testing, either by the client's team or under a DeployOpen retainer. The step is done when a staging upgrade has been rehearsed and a named owner has signed the runbook.
Questions buyers ask before choosing Keycloak, Logto or Zitadel
Is self-hosting Keycloak, Logto or Zitadel cheaper than a managed cloud service?
It depends on what you pay for and who pays for it. Self-hosting removes the vendor's subscription fee for the software you run, but you carry the infrastructure, database, upgrades, backups, monitoring and on-call work. Logto OSS documents minimum sizing of at least 2 vCPU, 8 GiB of memory and 256 GiB of disk, and Keycloak and Zitadel both need a production relational database (PostgreSQL 14 to 18 for Zitadel and Keycloak). Managed options such as Logto Cloud and Zitadel's hosted service bill by their own pricing, so ask each vendor for current plan terms in writing. Ask for a quote that separates one-time setup from recurring run costs, and state which environment and staffing assumptions it uses.
How much platform staff time does each identity platform need to run?
Effort is driven mainly by database operations, high availability design and upgrade cadence, not by the license. Keycloak plans four minor releases a year and says breaking changes in minor releases will be opt-in, but production still needs a synchronously replicated database for its high availability designs. Zitadel recommends Kubernetes with the official Helm chart for high availability, which adds cluster skills to the job. Logto's Docker Compose path bundles a Postgres database that is recreated on each run, so it is not suitable for production. Ask your team to map the upgrade, backup and on-call tasks for each option against the skills you already have.
Can our internal team run one of these platforms without outside help?
A team with Linux, container and PostgreSQL experience can run any of the three, but production readiness depends on details that are easy to miss. Keycloak's default dev-file database is for development only, and Logto's Compose file is not for production. Self-hosted Logto OSS supports only one administrator account by default, so teams that need several admins must confirm licensing before go-live. DeployOpen plans, implements, hardens, backs up, upgrades and documents self-hosted platforms inside your infrastructure, typically under a fixed scope agreed in writing before work starts. Ongoing support and upgrades are available as retainers.
How long does a migration to Keycloak, Logto or Zitadel take?
No supplied source gives a general migration duration, so treat any figure you hear as unverified until it is tied to your environment. The main drivers are the number of applications, how many user stores you must move, whether passwords can be migrated, and how many redirect URIs and client configurations need rework. Zitadel documents migration guides from Auth0, Keycloak, Firebase and another Zitadel instance, including just-in-time migration. Keycloak can run its database migration automatically at startup, or you can apply the SQL yourself, which its upgrading guide suggests for large deployments. Ask for a plan that lists each application, its cutover method and its rollback path.
Which of these licenses forces a commercial agreement?
Keycloak is Apache-2.0 and Logto's repository is MPL-2.0, so neither requires a commercial agreement to self-host the open source server. Zitadel moved its core, Console and hosted login to AGPL-3.0 with v3.0 on March 31, 2025, while APIs, SDKs, Helm charts and Terraform configurations stay Apache 2.0. The AGPL obligations apply when you modify and network-serve the server, and Zitadel offers a commercial license for teams that cannot meet them. Have counsel review your modification and distribution plans, and ask Zitadel whether a commercial license is needed for your use case.
Do Keycloak, Logto and Zitadel each support SAML and SCIM?
All three list SAML support, but SCIM coverage needs checking case by case. Keycloak supports OpenID Connect, OAuth 2.0 and SAML 2.0 and federates users from LDAP or Active Directory. Logto states full support for OpenID Connect, OAuth 2.1 and SAML, and lists enterprise SSO and organizations. Zitadel implements OpenID Connect, OAuth 2.0 and SAML 2.0 and provides a SCIM v2 service provider interface for provisioning. Because feature availability can differ by edition, deployment type and release, ask each vendor to confirm SAML and SCIM behavior for your specific tenant model and identity providers before you commit.
Which platform should a B2B SaaS team check first for tenant isolation?
Start with how each platform models tenants, because that shapes your operating model. Zitadel organizes tenants as instances with full data isolation, and organizations inside them, which suits products whose customers manage their own users. Logto offers multi-tenancy with organization RBAC and just-in-time provisioning. Keycloak has realms and an Organizations feature. Confirm with each vendor how customer-managed identity providers, admin delegation and audit data are scoped before you design your tenancy model. Architecture decisions made early are costly to reverse.
How DeployOpen helps choose and implement the right identity platform
DeployOpen plans, implements, customizes, integrates, hardens, documents and supports self-hosted open-source platforms inside your own cloud accounts, data centers or air-gapped networks. For the Keycloak, Logto and Zitadel decision, we start with the use case, then build and hand over only the platform your team can run.
How we scope
- Confirm whether the workload is B2B SaaS, consumer login, or internal workforce SSO before comparing platforms.
- Record license obligations, including Apache-2.0, MPL-2.0 and AGPL-3.0 terms, against how you plan to modify or embed the server.
- Agree the written, fixed scope, deliverables and timelines before any work starts, with ongoing support available as a retainer.
How we build
- Deploy the chosen platform with a production database such as PostgreSQL, not a development file store.
- Configure SAML, OIDC, SCIM or organization login only for the protocols your applications and customers require.
- Test tenant isolation, admin delegation and identity provider federation against documented scenarios before go-live.
How we hand over
- Document the architecture, tenant model, upgrade path and database backup and restore steps for your operators.
- Walk your platform, security and identity teams through configuration, administration and day-two runbooks.
- Deliver written evidence of configuration and testing that your internal reviewers or external auditors can assess.
How we support
- Plan upgrades around each project's release cadence and test them in a staging environment before production.
- Run security testing of the identity layer and its integrations as part of an agreed retainer or separate scope.
- Review licensing and edition changes with you when a vendor changes terms or a feature you rely on moves to a paid tier.
