Keycloak vs Kanidm: which to choose

Keycloak or Kanidm: when each one is the right choice

Choose Keycloak when the core job is enterprise single sign-on for web and SaaS applications that still require SAML 2.0, and when users already live in LDAP or Active Directory that Keycloak must federate. Choose Kanidm when the estate is Linux-heavy and you want passkeys, Unix login, SSH key distribution and RADIUS from one platform. The decision turns on four questions: whether any application needs SAML (Kanidm has no SAML support today, and its maintainers steer users toward OAuth2/OIDC first and LDAP app passwords second), where your existing directory sits, whether your administrators prefer a web console or a command line, and how comfortable your team is with a CLI-first tool as the main administration surface.

Run a short inventory before you pick. List every application and its protocol, note which ones need SAML metadata exchange or a directory they cannot change, and record which Linux hosts need Unix authentication and whether any depend on RADIUS. Ask the vendors or your own tests to confirm the exact protocol and LDAP behavior your applications expect, since a missing protocol usually surfaces late in a pilot. Also check that your team can operate the chosen database and clustering model: Keycloak requires a relational database in production and a synchronously replicated database for its supported high availability designs, while Kanidm uses its own storage and replication instead of an external SQL database.

Keycloak carries more configuration and a larger administration surface, which suits organizations with platform staff who will run a realm model, a browser-based admin console and an Operator or VM deployment. Kanidm carries a smaller surface that rewards engineers who manage identity as code and accounts from a terminal, but it asks the team to accept a narrower feature set. If you need both, a common pattern is to keep Keycloak as the application-facing SSO hub and federate it to a directory, which the sibling topic on Keycloak and FreeIPA covers in more depth. Confirm your choice against a written test plan before you commit, because switching identity providers later is costly.

Which scenarios favor Keycloak and which favor Kanidm

This table maps common identity scenarios to the platform that fits each one, with the condition that drives the choice. Read each row against your own protocol list and estate: Kanidm has no SAML support and its LDAPS gateway is read-only, so those two facts settle many enterprise SSO cases before anything else.

Scenario	Better fit	Condition that drives the choice
SAML-dependent SaaS integrations	Keycloak	Keycloak supports SAML 2.0 as a server. Kanidm has no SAML, and its maintainers steer users toward OAuth2/OIDC first and LDAP app passwords second.
Active Directory federation	Keycloak	Keycloak federates users from LDAP or Active Directory. Kanidm's LDAPS gateway is read-only, so it does not fit a design that needs writes back to the directory.
Linux workstation and SSH login	Kanidm	Kanidm provides Unix login, TPM-protected offline authentication and SSH key distribution in its feature list. Keycloak is not built for host login, so a separate Linux identity layer is usually needed.
Passkey-first workforce login	Kanidm	Kanidm lists passkeys including attested passkeys as a core feature. Keycloak can use WebAuthn, but confirm the exact passkey flows and attestation handling you need in its documentation.
RADIUS for network gear	Kanidm	Kanidm lists RADIUS in its README. Keycloak does not list RADIUS as a native protocol, so confirm any RADIUS requirement with the vendor or through a separate component.
Legacy apps that need LDAP	Depends on direction	Keycloak can federate from an existing LDAP directory. Kanidm's read-only LDAPS gateway serves legacy readers, but apps that write to LDAP will not work against it.
Enterprise SSO hub with many SaaS apps	Keycloak	Keycloak offers SAML, OIDC, identity brokering and an admin console. Kanidm is administered mainly through its CLI, which suits platform teams more than broad app-owner administration.
Database and operations preference	Kanidm	Kanidm uses its own replicated store with no external SQL database. Keycloak requires a supported relational database and a synchronously replicated database for its HA designs.

How each platform is built and what that means for operations

Keycloak and Kanidm make different bets about where state lives, how the server is deployed and who runs it day to day. The cards below cover the decisions those bets force on your team, from the database you back up to the admin tooling your operators learn.

Keycloak needs an external database

Keycloak is a Java server that expects a relational database in production, and its default dev-file database is for development only. Your team must choose a supported engine such as PostgreSQL 14 to 18, MariaDB, MySQL, Microsoft SQL Server, Oracle Database or Amazon Aurora PostgreSQL, then provision, back up and patch it alongside Keycloak. For high availability, the documented designs require a synchronously replicated database. Check whether your DBA team already runs that engine and how they test restores.

Kanidm owns its data layer

Kanidm does not use SQL as its database. It stores data in its own durable key-value layer, with its own caching, indexing and eventually consistent replication, so there is no separate database cluster to size or back up. The trade-off is that your backup and restore procedures follow Kanidm's tooling rather than the database practices your team already has. Ask the vendor or your own testing how Kanidm backups are scheduled, verified and restored before you commit.

Keycloak Operator upgrades need approval gates

On Kubernetes or OpenShift, the Keycloak Operator is usually installed through Operator Lifecycle Manager and manages Keycloak, KeycloakRealmImport, KeycloakOIDCClient and KeycloakSAMLClient resources. The Operator documentation strongly recommends manual approval mode for updates so that upgrades do not happen unannounced. Your platform team must own that approval step, plus the database and realm migration checks that come with each change. Teams without Kubernetes skills should weigh this before choosing the Operator route.

Kanidm is CLI-first

Kanidm administration is offered primarily through its command-line interface, while its web UI is designed mainly for user interactions such as self-service. Operators who prefer a console for day-to-day changes will need to script or train for CLI work, and audit practices should cover commands run from terminals. Keycloak's admin console is the main tool for most administrators, so the skill mix differs. Confirm that your operators are comfortable working from the shell before you plan the rollout.

Kanidm enforces TLS everywhere

Kanidm treats TLS for all connections as mandatory rather than an optional layer added later. That simplifies the security baseline, but it also means every client, LDAPS consumer and Unix host must trust the certificates you issue and rotate them on schedule. Keycloak can be configured for production TLS, but the setup is your responsibility and is part of the production checklist. Plan certificate issuance and renewal for every integrated system before the first login is tested.

Capabilities side by side: protocols, identity integration and tooling

This table compares protocol support, directory integration, Linux features, administration and high availability for Keycloak and Kanidm. Kanidm's documented features are listed as published, and rows marked to confirm need a test in your own environment before you commit to either platform.

Capability	Keycloak (Apache-2.0)	Kanidm (MPL-2.0)
SAML 2.0	Supported for applications and brokered logins	Not offered. An open feature request exists, and maintainers advise OAuth2/OIDC first
OpenID Connect and OAuth 2.0	Supported, with single sign-on across registered clients	Built-in OAuth2/OIDC provider with token exchange and an application portal
LDAP or Active Directory federation	Reads users from LDAP or Active Directory directories	No federation from an external directory is documented. Confirm before planning a migration
Identity brokering	Brokers logins to external OIDC or SAML providers	Not documented in the supplied material. Confirm with the project before relying on it
Passkeys and WebAuthn attestation	Confirm passkey and attestation options in the current release	Passkeys (WebAuthn) including attested passkeys are listed as features
RADIUS, Unix login and SSH keys	Not a documented feature. Confirm if network or Linux login is required	RADIUS, Unix integration with TPM-protected offline login and SSH key distribution
LDAPS access for legacy systems	Acts as an LDAP client to directories, not as a directory server	Read-only LDAPS gateway for legacy systems that need directory lookups
Admin console versus CLI	Web admin console for realms, clients and users, plus Operator resources on Kubernetes	Administration is primarily through the CLI. The web UI focuses on user self-service
High availability design	Single cluster across zones or multi-cluster v2; both need a synchronously replicated database	Two-node replication with its own database, so no external SQL database is required

How database and high availability design differ

Keycloak's high availability begins with the database. Keycloak needs a relational database in production, and the supported options include PostgreSQL 14 to 18, MariaDB, MySQL, Microsoft SQL Server, Oracle Database, Amazon Aurora PostgreSQL, EnterpriseDB Advanced and Azure SQL. Keycloak documents three HA architectures: one cluster optionally spread across availability zones, the multi-cluster v2 design that does not need an external Infinispan cluster, and the deprecated multi-cluster v1 design. Both supported designs require a synchronously replicated database, so the database is a dependency you must size, patch and fail over yourselves. Confirm with your DBA which replication mode your platform offers before you commit to a topology, and check the Keycloak database guide for the current engine list.

Kanidm takes the opposite route. It does not use SQL as a database. It stores data as a durable key-value store, implements its own caching, querying and indexing on top, and uses its own eventually consistent replication, so there is no external database to provision for identity data. The README describes two-node high availability through replication. That shrinks the component list, but it moves the failure modes into Kanidm's replication model. Your team should test what a split between the two nodes does to sessions and account changes, and confirm how Kanidm's own backup and restore procedure fits your recovery targets. Do not assume a two-node pair is equivalent to a synchronously replicated database cluster across availability zones.

The ownership question decides much of this comparison. With Keycloak, a database team or cloud service owns backup, point-in-time recovery, replication lag, failover testing and version upgrades, and the Keycloak team owns the schema migration, which runs automatically at startup by default unless you choose manual migration for large deployments. With Kanidm, the identity team owns the whole data path, which lowers the number of teams involved but concentrates specialized knowledge in fewer people. Ask each vendor or partner for a written backup, restore and failover runbook, and rehearse a node loss before go-live.

What the licenses allow and what is paid for

Keycloak is licensed under Apache-2.0, a permissive license that lets you run, modify, embed and redistribute the server, including inside commercial products, as long as you keep the license text and notices. The project publishes community releases, and the current release is 26.8.1, published October 13, 2026. Since Keycloak 26.0 the project plans four minor releases a year and says breaking changes in a minor release will be opt-in. Red Hat build of Keycloak is a separate, supported distribution based on the open source project, and it replaces Red Hat Single Sign-On. Red Hat's product page showed version 26.6 as its latest, so confirm the current version there before you plan an upgrade path.

Community releases: you can download and run the server at no license fee, but the license itself carries no support obligation. Confirm which community channels your team will rely on during an incident.
Apache-2.0 obligations: keep the license and notices with any redistributed build. The license does not require you to publish your own modifications.
Red Hat build: the supported distribution is sold through a Red Hat subscription. Compare its documented differences with upstream Keycloak before you choose it.
Existing Red Hat Single Sign-On estates: if you already run Red Hat Single Sign-On, the Red Hat build is the product that replaces it, so check that path with Red Hat.
Subscription scope: the subscription is the paid line item. Ask Red Hat for its terms directly, since they are separate from the upstream license.

Check the LICENSE file and the release notes for the exact version you plan to run.

Release windows and how upgrades differ in practice

Keycloak and Kanidm ask for different maintenance habits. Keycloak plans four minor releases a year and a major release every two to three years, and says breaking changes in a minor release will be opt-in, so an upgrade to a new minor line should not change behavior until you enable the change. Its database schema migrates automatically at startup by default. For a small cluster that is convenient, but on a shared production database the startup migration runs on your change window, not in a test. Ask your team to decide, before the first upgrade, whether schema changes will be applied by Keycloak at boot or applied as SQL by a DBA, which the upgrading guide suggests for large deployments. Read the Keycloak upgrading guide for each target version before you schedule it.

Kanidm releases quarterly, on February 1, May 1, August 1 and November 1, and supports each stable release for four months. Upgrades are allowed only from the previous minor version, so moving from 1.2.0 to 1.3.0 works, but jumping to 1.4.0 from 1.2.0 does not. That rule means a platform that falls behind must step through each intermediate minor release, and a deployment that misses its window can drop out of support before the next step is planned. Kanidm's support guidelines set the rules you should check against each release you run.

Plan the calendar around the shorter clock. For Kanidm, a quarterly upgrade with a four-month support window means you should plan for at least one upgrade per quarter, with a test instance running the next minor release ahead of the production date. For Keycloak, four minor releases a year still need a standing monthly or quarterly review of release notes, with a named owner who decides which minor line to adopt. Confirm current support windows for your Keycloak distribution with the vendor or your Red Hat subscription, since the supplied facts do not give an end-of-support date for upstream minor lines. Budget the recurring time in your team's plan as an operating cost.

What drives the running cost of each platform

Running Keycloak and Kanidm costs different things. Keycloak adds database, cluster and Java or Kubernetes operating work, while Kanidm moves most of that into nodes, Linux administration and its quarterly upgrade cadence. Use these cards to build a written scope that compares like with like.

Database and cluster infrastructure

Keycloak needs a relational database in production, and its high availability designs require a synchronously replicated database. You or your database team typically own the instances, backups, failover and licensing for the chosen engine, which recur every month. Kanidm uses its own database and replication, so its main infrastructure is the nodes themselves, including the two-node high availability setup. Ask the vendor or integrator to price each database engine option, the number of Keycloak nodes per site, and who operates the database.

Skills to run each platform

Keycloak operations draw on Java tuning, clustering and, for the Operator, Kubernetes. Kanidm operations draw on Linux, the CLI and identity design, because its README positions the CLI as the main administration path and the web UI for user tasks. Staff time is a recurring cost that is hard to see on an invoice. Ask for named roles, hours for handover, and whether training or runbooks are included in the fixed scope.

Upgrade effort and release cadence

Keycloak plans four minor releases a year and says breaking changes in minor releases are opt-in, so upgrade work is recurring but predictable. The Operator documentation strongly recommends manual approval for updates. Kanidm releases quarterly and supports each stable release for four months, and upgrades only from the previous minor version, so skipping a release forces extra steps. Budget test cycles for each cadence and ask whether the retainer covers upgrades on a fixed schedule.

Support contracts and paid editions

Keycloak is Apache-2.0 with no paid core edition, but Red Hat build of Keycloak is a supported distribution that carries a subscription. Kanidm is MPL-2.0 and any vendor support is a separate agreement you must confirm. Support fees are usually one-time to set up and recurring to maintain. Ask whether a quote covers vendor support, incident response hours, and upgrade assistance, and who is the first contact for each.

Cost of SAML and application integrations

Each SAML-based application adds configuration, certificate handling and testing work. Kanidm has no SAML support, and its maintainers steer users to OAuth2/OIDC first and LDAP app passwords second, so SAML-only applications may need a different platform or a bridge. Keycloak handles SAML natively but each client still needs mapping and renewal. Ask for a per-application estimate that lists the protocol, the connector work, and the testing and certificate rotation effort.

Moving from one platform to the other

This sequence turns a move between Keycloak and Kanidm into a tested, parallel cutover, so each application keeps working and the team knows which identities, protocols and factors moved and which had to be rebuilt.

Inventory applications, protocols and dependencies
List every application that authenticates against the current platform and record the protocol each one uses: OIDC, OAuth 2.0, SAML 2.0, LDAP, RADIUS or Unix login. Note which applications depend on a Keycloak SAML client, because Kanidm has no SAML support and those applications must either move to OIDC or stay on Keycloak. Include SSH key distribution, VPN or network devices that use RADIUS, and Linux hosts that rely on Unix authentication. The team that owns each application confirms its protocol and redirect URIs. The output is a signed-off inventory with a target platform for every entry.
Map users, groups and authorization rules
Document how users, groups and roles are organized today, and how each group maps to a Kanidm group or to an application-side role. Identify which accounts come from LDAP or Active Directory federation in Keycloak, because those accounts are typically still owned by the directory and may not need to be exported. Decide which accounts are local to the current platform and need a data export, and confirm with the vendor documentation which attributes and credentials can be moved. The output is a mapping sheet that a second person has reviewed, with every group and role assigned a destination.
Rebuild clients and OIDC registrations
In Kanidm, create the OAuth2/OIDC resource servers and client registrations for each OIDC application, including redirect URIs, scopes, claims and any token exchange flows. Keycloak client settings such as protocol mappers, custom claims and fine-grained authorization policies do not carry over automatically, so each one is recreated and compared against the original. SAML applications that are moving to OIDC need their relying-party configuration rewritten on the application side as well. The check is that each application completes a sign-in in a non-production environment and receives the same claims it received before.
Recreate RADIUS, Unix and SSH configuration
Configure the Kanidm Unix integration on Linux hosts, including any TPM-protected offline authentication the team intends to use, and set up SSH key distribution for administrative access. Rebuild RADIUS settings for network devices and VPN concentrators, and confirm any read-only LDAPS gateway consumers still bind and search as expected. These pieces are not exported from Keycloak, so each host or device is tested individually. The output is a test matrix showing each host, device and service with its login result and the group it resolves to.
Test authentication flows, MFA and passkey enrollment
Run scripted and manual tests for each sign-in path: password plus second factor, passkey registration, passkey sign-in, account recovery, and session expiry. Kanidm supports passkeys (WebAuthn), including attested passkeys, and Keycloak supports its own credential types, so enrollment must be repeated for each user rather than assumed to carry over. Confirm that users with lost devices can recover access through the process the organization has defined. The check is a written test record covering each flow, the tester, the result and any fix that followed.
Run both platforms in parallel
Keep the current platform serving production traffic while the new one serves a pilot group of users or a set of low-risk applications. Route sign-ins to the new platform for those applications only, and compare audit logs, token claims and failure rates between the two. Keep the rollback path documented and tested, including how to switch an application back to the original client. Kanidm documents two-node high availability through replication, so confirm the pilot environment reflects the production topology before relying on it. The output is a pilot report that lists issues found and their resolution.
Cut over and retire the previous platform
Move the remaining applications in agreed waves, with a named owner and a rollback decision point for each wave. Once every application has authenticated through the new platform for an agreed observation period, disable sign-ins on the old platform rather than deleting data immediately. Keep the last exported configuration and audit records under the organization's retention policy. The migration is complete when the application inventory shows every entry on the target platform, the rollback window has closed, and the old platform is decommissioned with that record filed.

Questions buyers ask before choosing Keycloak or Kanidm

How much effort does each platform take to run day to day?

Keycloak asks for more upfront configuration, while Kanidm asks for more deliberate administration planning. Keycloak needs a relational database in production, and the Kanidm README says deploying Keycloak requires significant configuration and expertise, a claim Kanidm's own comparison makes, so treat it as the vendor's view and test it. The recurring work includes database operations, realm and client configuration, and upgrades. Keycloak's project plans four minor releases a year, and breaking changes in minor releases are opt-in. Kanidm releases quarterly, supports each stable release for 4 months, and supports upgrades only from the previous minor version, so your upgrade cadence has to keep up. Administration is primarily through its CLI, so plan for that skill set on your team.

Can our team run Keycloak or Kanidm without outside help?

A team with Java, database and Kubernetes or VM skills can run Keycloak, but the first deployment and the hardening are where teams usually want a second pair of hands. Kanidm suits a team comfortable with Linux, TLS and command-line administration, because TLS is mandatory and the web UI is designed for user tasks rather than administration. Ask yourself who will own the database, the upgrade calendar and the on-call rotation after go-live. An outside partner can plan, implement, document and support either platform under a written, fixed scope, and ongoing support is available as a retainer. Whether you need that help depends on your in-house skills and how many applications you must onboard.

How long does a typical Keycloak or Kanidm implementation take?

No supplied figure gives a typical duration, so confirm timelines against a written scope rather than a generic estimate. The main drivers are the number of applications and protocols to onboard, whether you federate LDAP or Active Directory, the high availability design you choose, and how many realms or user stores you need. For Keycloak, database choice and the high availability architecture add planning steps, and the database must support synchronous replication for the supported HA designs. For Kanidm, the built-in replication and database reduce external components, but the work shifts to modeling groups, Unix integration and identity lifecycle. Ask any provider for a milestone plan with named dependencies.

Can Kanidm replace Keycloak for SAML applications?

Not as a direct replacement today. SAML is not among Kanidm's listed features, and the open GitHub issue proposing it from August 2023 has not been resolved. The maintainers advise guiding applications to OAuth2 or OIDC first, LDAP app passwords second, and SAML only as a last resort. If your estate depends on SAML service providers, Keycloak covers SAML 2.0 natively, and it can broker logins to external SAML identity providers. If you want Kanidm for Linux and passkeys, confirm early which SAML applications must be migrated to OIDC or handled another way, because that work can dominate the project.

What does the work need from our staff?

Expect to supply application owners, an identity owner with authority over user lifecycle, and platform or infrastructure staff for hosting, networking and certificates. For Keycloak you also need database administrators for the chosen engine, and for Kubernetes deployments the Operator and cluster skills. For Kanidm, the people who manage Linux hosts, SSH keys and Unix groups are central, since those are the workloads it targets. Ask the provider to list each client task, the staff role it needs, and the decisions only your organization can make, such as directory source of truth and MFA policy. Your staff time is a real cost even when an external partner does the build.

Which platform costs less to own over time?

Both upstream projects are free to download and run, so the difference is in the labor and any paid support you buy. Keycloak's Red Hat build is a supported distribution, and Red Hat's product page showed version 26.6 as its latest, so ask Red Hat for current terms if you need vendor support. Kanidm is MPL-2.0 and carries no separate enterprise tier in the facts supplied, so confirm support options directly with its maintainers. Recurring costs include staff time for upgrades, database operations for Keycloak, and any retainer for ongoing support. Ask any provider to price one-time implementation and recurring support separately, with the upgrade cycle written into the scope.

Which platform fits enterprise SSO and which fits a Linux-heavy estate?

Keycloak fits enterprise SSO when you need SAML and OIDC for many applications, brokering to external identity providers, and LDAP or Active Directory federation with an admin console. Kanidm fits a Linux-heavy estate when you want Unix login with TPM-protected offline authentication, SSH key distribution, RADIUS, passkeys and a read-only LDAPS gateway for legacy systems, all from one platform. Many organizations with a Windows directory and SAML-heavy SaaS will find Keycloak the better match. Organizations with mostly Linux hosts and OIDC applications may find Kanidm sufficient. Test your three most important application types against both before deciding.

How DeployOpen helps choose, implement or migrate

DeployOpen is a Chainscore Labs company that plans, implements, integrates, hardens, backs up, upgrades, documents and supports self-hosted open-source platforms inside your own infrastructure. For Keycloak vs Kanidm, we start with the applications, protocols and Linux estate you need to serve, then build the identity platform that fits them.

How we scope

We confirm which applications need SAML, OIDC or LDAP, and which Linux hosts need Unix login, SSH keys or RADIUS.
We document the database, high availability and hosting target before any build work starts.
Engagements are fixed-scope, with deliverables and timelines agreed in writing before work begins.

How we build

We deploy Keycloak or Kanidm in your cloud account, data center or air-gapped network, as the written scope states.
We configure identity brokering, federation, clients and admin tooling, and test login paths for each application.
We test failover for the chosen high availability design and record the results against the agreed scope.

How we hand over

We deliver runbooks for upgrades, backups, admin tasks and the chosen release support window.
We document configuration, architecture decisions and any migration steps for applications moving between platforms.
We walk your administrators through the running platform so your team can operate it after handover.

How we support

Ongoing support, upgrades and continuous testing are available as retainers after handover.
We can plan upgrades around each platform's release cadence and support windows, as set out in the written scope.
Retainers can cover periodic security testing of the identity platform and its integrated applications.

Keycloak vs Kanidm