Apps get a signed token and never see passwords
Keycloak is an identity and access management server written in Java and released under the Apache 2.0 license. Applications hand login off to it: they redirect the user to Keycloak, which authenticates them and returns a signed token over OpenID Connect, OAuth 2.0 or SAML 2.0, so the application never sees a password. Accounts live in Keycloak's own database or in an LDAP or Active Directory server it federates, grouped into realms that are isolated from one another. Keycloak joined the CNCF as an incubating project on April 10, 2023.
The comparison of self-hosted SSO tools weighs what Keycloak asks of a server against the other tools.
Your LDAP stays put, with fine-grained authorization on top
- OpenID Connect, OAuth 2.0 and SAML 2.0 on the application side, with single sign-out: logging out once ends the session in every connected application.
- Existing directories stay where they are: LDAP and Active Directory, a Kerberos bridge, SSSD and FreeIPA, or an SPI for any other user store. Another OpenID Connect or SAML provider, or a social login such as Google or GitHub, is set up in the admin console with no change to application code.
- Built-in MFA and strong authentication: TOTP and HOTP, passkeys and WebAuthn, recovery codes, plus X.509 client certificates and step-up authentication.
- Login flows you can rearrange step by step in the console. With passkeys enabled, the default flow skips the second factor for a user who signed in with one.
- Authorization beyond roles: the authorization services manage fine-grained policies from the same console, and the SCIM API for users and groups is fully supported as of 26.8.0.
JVM, relational database and 1.25 GB per instance
A JVM and a relational database are mandatory. Keycloak runs on OpenJDK 17, 21 or 25, and the official container image ships OpenJDK 21. The default dev-file database is for development only. Production needs PostgreSQL (14 through 18), MariaDB, MySQL, SQL Server or Oracle, the one engine whose JDBC driver is not bundled.
Budget about 1.25 GB of memory per instance. The sizing guide puts the baseline at 1,250 MB per instance, including caches and 10,000 sessions, and the container guide recommends a 2 GB limit for smaller production deployments. Without a limit, the Java heap can grow to 70% of the container's memory. For comparison, Zitadel puts its own process at roughly 512 MB, and authentik asks for at least 2 CPU cores and 2 GB of RAM for its Docker Compose install.
Most of the CPU goes into password hashing. The sizing guide budgets 1 vCPU per 15 password logins per second with the default Argon2 hashing, then adds 150% headroom for load spikes and failover.
Production mode refuses to start without a hostname and TLS. Run kc.sh start with no further configuration and it disables plain HTTP and exits with an error; start-dev is for trying things out. Build options, the database vendor among them, are baked in with kc.sh build to produce an optimized image, which the Kubernetes operator requires for any custom image.
A typical production setup runs two or more instances. They form an Infinispan and JGroups cluster so logins keep working when one goes down. The production guide covers deployments from a few thousand on-premise users up to millions. On Kubernetes, the supported platform is OpenShift 4.18 to 4.21; EKS, AKS and other distributions get best-effort support only.
Four minor releases a year. The cadence, announced in October 2024 after 26.0, also calls for a major every two to three years, with breaking changes kept opt-in until the next one. It has held so far in 2026: 26.5 in January, 26.6 in April, 26.7 in July, 26.8.0 on October 1. The 26.7 branch got its fifth patch release the day before 26.8.0 came out.