Keycloak vs Dex: which to choose

Keycloak vs Dex: when each one fits a platform team

Start with where your users already live. A platform team that mainly needs kubectl and cluster tooling to sign in usually has a directory or an upstream identity provider already, and needs one OIDC issuer in front of the Kubernetes API server. Dex fits that case well. It is a single static Go binary configured through one YAML file, it keeps no users of its own, and it defers authentication to LDAP, GitHub, OIDC or other upstreams. The condition is that the upstream already holds the accounts and groups you need. If it does not, Dex gives you nowhere to create them, and you will need a different tool. Dex also runs natively on Kubernetes with Custom Resource Definitions, although its own documentation notes that CRD storage may not suit a large number of users, so confirm your user count against the storage options before you choose it.

Decide whether you must own users and SAML. Keycloak suits a team that has to hold its own user store, organize access into realms, give administrators a console, and broker logins to external OIDC or SAML providers. Its SAML support is the deciding factor for many business applications. Dex's SAML 2.0 connector is marked stable in the README, but the same README warns that the connector is unmaintained and likely vulnerable to auth bypasses, and SAML logins through Dex issue no refresh token, which matters for kubectl sessions that need offline access. If SAML into business applications is a requirement, Dex is not a credible answer for that path, and Keycloak becomes the default candidate. Confirm the current status of any connector you plan to use against the Dex repository before committing.

Price the operating weight honestly. Dex is lighter to run because it needs no relational database when etcd or CRDs suit your scale, while Keycloak requires a production database such as PostgreSQL 14 to 18, along with clustering, upgrades and a configured high availability design. That weight buys you user management, admin tooling and broader protocol coverage. Ask your team who will operate the database, plan Keycloak upgrades, and own the Operator approval policy. If the answer is nobody, a single OIDC broker in front of an existing directory is the lower-effort path. If a business application estate depends on SAML and self-service administration, the extra operating load is the cost of meeting that need.

Which platform fits which scenario

This table maps common platform team scenarios to the better fit between Keycloak and Dex, with the supplied facts behind each choice. Read each row for the condition that decides it, and treat a Dex pick as a sign the team needs only a thin broker, not a user store.

Scenario	Better fit	Reason
kubectl and cluster sign-in against an existing LDAP or GitHub directory	Dex	Dex runs natively on Kubernetes, drives API server OIDC authentication and has stable LDAP and GitHub connectors, so the directory stays the source of identity.
kubectl sign-in that needs offline access through a SAML upstream	Keycloak	Dex issues no refresh token after a SAML login, and kubectl offline access depends on refresh tokens, so Keycloak's own OIDC session handling is the safer choice.
Enterprise apps that only support SAML 2.0	Keycloak	Keycloak serves SAML 2.0 as a provider, while Dex's SAML 2.0 connector is unmaintained and carries a documented auth bypass warning, so it should not be the SAML front door.
Team with no user store that wants a thin broker	Dex	Dex keeps no users and defers authentication to upstream providers, so there is no database or user lifecycle to run beyond optional storage.
Multi-application SSO estate needing an admin console and realms	Keycloak	Keycloak provides an admin console, realms, identity brokering and user federation in one server, which Dex does not offer.
Regulated environment that must own the user lifecycle and its evidence	Keycloak	Keycloak needs a production relational database and holds its own users and admin records, giving the platform team a controllable store to document for assessors.
Single static binary on a small cluster with existing upstream identity	Dex	Dex is a single static Go binary with optional, pluggable storage, which keeps the operational footprint small when upstream providers already hold the accounts.
Team that must patch and upgrade the identity layer on a fixed schedule	Keycloak	Keycloak publishes four minor releases a year with opt-in breaking changes, giving a predictable upgrade path that the team must still plan and test.

How Keycloak and Dex are built and deployed

Keycloak and Dex solve the sign-in problem at very different weights. One is a full identity server that owns its database, and the other is a configuration-driven broker that owns almost nothing, so the operating burden follows from those choices. The cards below cover what each one needs to run, how it is upgraded, and what high availability requires before you commit.

Keycloak is a Java server with a database

Keycloak runs as a Java server and needs a relational database in production. Its supported engines include PostgreSQL 14 to 18, MariaDB, MySQL, Microsoft SQL Server, Oracle Database and Amazon Aurora PostgreSQL. The default dev-file database is for development only. Plan the database as a first-class component with its own backups, patching and capacity, because user, realm and client state all live there. Confirm which engine your DBA team supports before you size the rest of the stack.

Dex is one static binary

Dex is a single static Go binary configured through one YAML file. The Dex website describes its storage as pluggable and optional, so it can run with no database of its own for some setups. This makes first deployment fast and low in moving parts. The trade-off is that Dex does not hold a user store, so there is little identity state to back up beyond its configuration and any chosen storage backend.

Dex storage choices shape backups

Dex can store state in etcd v3, Kubernetes CRDs, SQLite3, PostgreSQL or MySQL 5.7 or later. The Dex documentation says CRDs may not suit a large number of users, and SQLite3 is only for standing Dex up quickly, not for real workloads. Choose the backend first, then define the backup and restore process for that backend. If you pick CRDs or etcd, your Kubernetes backup tooling becomes part of your identity recovery plan.

Keycloak Operator installation paths

The Keycloak Operator installs through Operator Lifecycle Manager, which Keycloak recommends, or with kubectl. It manages Keycloak, KeycloakRealmImport, KeycloakOIDCClient and KeycloakSAMLClient resources. The Operator documentation strongly recommends manual approval mode for operator updates, so upgrades happen when your team decides. Confirm who owns OLM subscriptions and approval in your cluster before go-live.

Upgrades differ in scope

Keycloak migrates its database schema automatically at startup by default, and it also supports manual migration where administrators apply the SQL themselves. The upgrading guide suggests manual migration for large deployments. Dex upgrades are lighter because its state sits in the storage you chose, but you still need to test configuration changes against each connector. Ask each vendor for its documented upgrade path and rollback limits before you set your change calendar.

Keycloak HA needs synchronous replication

Keycloak documents three high availability designs: one cluster optionally spread across availability zones, multi-cluster v2 without an external Infinispan cluster, and the deprecated multi-cluster v1. Both supported designs need a synchronously replicated database. Dex high availability depends on the storage backend you chose and on how many replicas your Kubernetes deployment runs. Before you design either, ask your database team whether synchronous replication across your sites is available and tested.

Feature comparison: Keycloak against Dex

This table compares Keycloak, a full identity and access management server with its own user store, against Dex, a federating OpenID Connect broker that holds no users. Read each row as a question of whether your platform needs the broker's narrow role or a complete identity server. Confirm connector status and Kubernetes login details against current documentation before you commit.

Capability	Keycloak	Dex
License	Apache-2.0	Apache License 2.0
Current release	26.8.1, published October 13, 2026	v2.46.0, released October 7, 2026
Protocols	OpenID Connect, OAuth 2.0 and SAML 2.0 for applications	Acts as an OpenID Connect provider to downstream apps; SAML is only consumed upstream through a connector
Own user store	Yes, with local users and passwords in its database	No; Dex owns no user state and delegates authentication to upstream providers
User federation from LDAP or AD	Yes, Keycloak reads users from LDAP or Active Directory	Yes through the LDAP connector, which defers authentication to the directory
Brokering to external identity providers	Yes, to external OpenID Connect or SAML providers	Yes, through connectors such as GitHub, Google, Microsoft and OIDC upstreams
Admin console and realms	Yes, web admin console with realms for separating users and clients	No admin console; configured through a single YAML file
Fine-grained authorization	Yes, authorization services are included	Not offered; access decisions stay in the downstream application
Kubernetes and kubectl sign-in	Keycloak Operator on Kubernetes; API server login through OIDC clients, confirm the kubectl flow with your cluster setup	Native to Kubernetes via CRDs, with kubelogin and kubectl sign-in through the Kubernetes OIDC plugin
Storage	Relational database required in production, such as PostgreSQL 14 to 18 or MariaDB	Optional; etcd, Kubernetes CRDs, PostgreSQL or MySQL, with SQLite3 only for quick trials
Connector maturity	Mature LDAP, AD, SAML and OIDC brokering, supported as part of the server	LDAP, GitHub and SAML 2.0 marked stable; OIDC, GitLab and Microsoft beta; Google and OAuth 2.0 alpha; SAML flagged unmaintained and likely vulnerable to auth bypasses
Refresh tokens for kubectl	Issued through standard OIDC flows, confirm offline access settings for your clients	Not issued for logins through the SAML connector, which matters for kubectl offline access

Licensing and paid options for each platform

Keycloak is licensed under Apache-2.0, which lets you run, modify and redistribute the server without a commercial license fee for the upstream project. It is a Cloud Native Computing Foundation incubating project, so its governance sits in a foundation rather than with a single company. The current community release is 26.8.1, published October 13, 2026. Since Keycloak 26.0, the project plans four minor releases a year and a major release every two to three years, and it states that breaking changes in a minor release will be opt-in. For paid support, Red Hat build of Keycloak is Red Hat's supported distribution based on the open source project and replaces Red Hat Single Sign-On. Red Hat's product page showed version 26.6 as its latest at the time of research, so the supported build can trail upstream.

Upstream license: Apache-2.0 applies to the community server, so the license cost is zero. You still pay for the people, infrastructure and database that run it.
Community cadence: Four planned minor releases a year means frequent upgrades. Plan a recurring upgrade window and test it against your realms and custom providers.
Opt-in breaking changes: Minor releases can change behavior only when you opt in, which lowers surprise risk but still requires reading each release note.
Red Hat build: The supported distribution replaces Red Hat Single Sign-On. Its subscription is a separate cost, and its version can differ from upstream.
Other support: Confirm with the vendor or a service provider which support terms, response windows and version matching apply to your chosen build.

Before you commit, confirm the support terms of the distribution you plan to run, and whether the Red Hat build version matches the upstream release line you need.

What drives the running cost of each

Running Keycloak and Dex costs differ less in license fees, since both are Apache 2.0, than in who operates the database, the Java runtime, the upstream directory and the upgrade cycle. Each card below names one cost driver, whether it is one-time or recurring, and what to ask for in a written quote.

Keycloak database and infrastructure

Keycloak needs a relational database in production, and the high availability designs both require a synchronously replicated database. The database license, hosting, backups and capacity are usually paid for by the client or its cloud account, and they recur every month. Ask the implementer to price the database tier, the number of Keycloak nodes, and the load balancer as separate line items, so the recurring footprint is visible before the design is signed off.

Dex footprint and optional storage

Dex is a single static Go binary, and its storage is pluggable and optional, so a deployment can run with no separate database at all. Its recurring infrastructure cost is therefore usually smaller than Keycloak's. The cost moves to the storage choice when it is made: Kubernetes CRDs may not suit a large number of users, and SQLite3 is intended only for quick trials. Ask which storage backend the quote assumes and who runs it.

Upstream directory dependency

Dex owns no user state and delegates authentication to LDAP, SAML, GitHub or OIDC providers, so its running cost includes the upstream directory's availability, password policy and offboarding process, which remain someone else's recurring work. Keycloak can also federate LDAP or Active Directory, but it can run without a directory. Confirm in the quote who maintains the upstream connection, who answers when it fails, and whether that work is in scope.

Skills to operate a Java IAM server

Operating Keycloak means running a Java application with its cluster behavior, database migrations, realm configuration and metrics, which requires platform skills that a small team may not hold in-house. Dex needs a smaller operational surface, but a platform team still needs Kubernetes and connector expertise. Ask whether the quote includes training for your staff, and how much of the monthly effort is handover versus ongoing operation.

Upgrade cadence and Operator approval

Keycloak plans four minor releases a year and says breaking changes in a minor release will be opt-in, so upgrade work recurs on a fixed rhythm. The Keycloak Operator documentation strongly recommends manual approval mode for operator updates to avoid unintended automatic upgrades. Choosing manual approval adds a recurring review and test step that someone must own. Ask the quote to state the upgrade window, the test environment and who approves each change.

One-time design and connector setup

Most of the first-year spend on either product is one-time: architecture design, realm or connector configuration, Kubernetes integration, and testing the kubectl sign-in path. Keycloak adds one-time work for database sizing and high availability design, while Dex adds it for connector selection and checking the maturity of each connector. The recurring cost starts after go-live, so ask the quote to split these phases and to name the exit deliverables.

Moving from Dex to Keycloak, or the reverse

This sequence moves a Kubernetes sign-in path from Dex to Keycloak, or back, without losing the directory data behind it. It ends with a tested kubectl login, a retired old issuer, and a written record of what was rebuilt.

Inventory clients, connectors and token consumers
The platform team lists every OIDC client registered with Dex, every connector in the Dex configuration file, and every consumer that reads tokens from it, including the Kubernetes API server, kubelogin profiles, CI runners and internal apps. For each connector, record whether it is LDAP, GitHub, SAML or another upstream, and note whether Dex's README marks it stable, beta or alpha. Done means a single inventory sheet that names an owner for each client and flags any SAML connector, because Dex's SAML 2.0 connector is marked unmaintained and likely vulnerable to auth bypasses. Confirm the connector status against the current Dex README before you rely on it.
Decide where user records will live
The security and identity team decides for each upstream whether users stay in the source directory and are federated into Keycloak, or whether Keycloak brokers logins to an external OIDC or SAML provider. Federation reads an LDAP or Active Directory tree, so directory data stays where it is. Brokering leaves passwords and MFA with the external provider. Dex keeps no users, so the choice mainly affects Keycloak's own user store and group model. Done means a signed decision per upstream and a named system of record for every user attribute Kubernetes RBAC depends on.
Stand up Keycloak and map groups and claims
The platform team deploys Keycloak in a non-production environment with a production-grade database, since Keycloak requires one outside development. They configure the chosen federation or brokering links, then map upstream groups to Keycloak groups and define the token claims that Kubernetes uses for usernames and groups. Group mappings from Dex connectors seldom carry over unchanged, so expect rework here. Done means a test user signs in through Keycloak and the resulting ID token contains the expected username and group claims, checked with a decoded token from a sample login.
Rebuild clients as Keycloak OIDC or SAML clients
Each Dex client is re-registered as a Keycloak client, either by hand in the admin console or as declarative configuration through the Keycloak Operator's KeycloakOIDCClient or KeycloakSAMLClient resources. The team records client IDs, secrets, redirect URIs and allowed scopes, and retires any client that is no longer needed. Issuer URLs change with the new realm, so every consumer must be updated. Done means each client completes a login against the Keycloak realm in the test environment, and the change log lists every rebuilt registration.
Repoint the Kubernetes API server and kubelogin
The cluster administrator updates the API server's OIDC issuer URL and client ID settings to the Keycloak realm, then updates each kubelogin configuration that users or pipelines run. Dex drives API server authentication through the Kubernetes OIDC plugin, so this is the step that changes the sign-in path for operators. Plan a maintenance window with the cluster owner and keep the old Dex configuration available for rollback. Done means a test user can run kubectl against the cluster with a token issued by Keycloak, and the API server logs show the new issuer accepted.
Test refresh-token behavior for kubectl
Dex issues no refresh token when a user logs in through its SAML connector, and kubectl sessions that need offline access depend on refresh tokens. The team tests each upstream path, including any SAML-based login, and confirms whether Keycloak issues refresh tokens for the kubectl client under the intended session lifetimes. Where a path cannot provide refresh tokens, the team records the workaround, such as shorter sessions or a different upstream. Done means a written test result per upstream showing that a kubectl session survives the expected token lifetime, or a documented limitation the cluster owner has accepted.
Cut over and monitor the new issuer
The team switches production users and pipelines to the Keycloak issuer during the agreed window, keeping Dex running in read-only standby for rollback. They watch authentication failures, group-based RBAC denials and token errors for an agreed period, then confirm that all clients appear in the Keycloak audit or event logs. Done means a sign-off from the platform owner that production logins succeed for each user group and each client in the inventory.
Retire the old issuer and record the result
Once the rollback window closes, the team removes Dex's connectors, clients and storage, revokes any Dex-issued secrets, and updates runbooks, diagrams and access reviews to name Keycloak as the issuer. The record should state what transferred (the directory data stayed in the source system) and what was rebuilt (client registrations, issuer URLs, token claim mappings and group mappings). Done means Dex no longer answers requests, the inventory is closed, and the change record is filed with the security team. The same steps run in reverse when moving from Keycloak back to Dex, with the caveat that Dex keeps no user store, so Keycloak-managed users must exist in an upstream directory first.

Where a Keycloak or Dex implementation usually runs long

The slowest part of a Keycloak or Dex project is rarely installation. It is the claim and group mapping across the upstream directory, because each identity source names users, groups and email attributes differently and the mapping has to be agreed before anyone can test access. Dex maps these through its connectors, while Keycloak maps them through identity provider mappers and LDAP or Active Directory attribute settings. Plan a working session with the directory owners to confirm which group becomes which Kubernetes group or application role, and which attribute is the stable user identifier. Changes to that mapping later tend to reach every downstream application at once, so treat it as a controlled change with a test account for each role.

The second source of delay is the API server itself. When Dex or Keycloak drives kubectl sign-in through the Kubernetes OpenID Connect settings, the issuer URL, the certificate chain and the client ID must match exactly, and any later change to the hostname or certificate forces a restart of the control plane configuration. Cluster admins should confirm who can change API server flags and how a rollback would work before the issuer goes live. On the SAML side, Dex's SAML 2.0 connector is marked unmaintained and likely vulnerable to authentication bypasses in its own README, so a SAML requirement pushes the project toward a different component. Keycloak's SAML support is part of the core product, but the application owners still need to supply signing certificates, entity IDs and assertion attribute lists, and that exchange usually takes several rounds.

Keycloak adds two recurring workloads that Dex does not. The first is database sizing and backup. Keycloak needs a supported relational database in production, and the database guide lists PostgreSQL, MariaDB, MySQL, Oracle Database, Microsoft SQL Server and others, so the database team must size, back up and restore it on a schedule they can prove. The second is compliance evidence. DeployOpen prepares systems, controls and evidence for assessments, but it does not issue audit reports or certifications, and independent auditors decide what is sufficient. Ask your compliance lead which controls must be documented, such as access reviews, administrator change logging and key rotation, and who will own each record. DeployOpen works under a written, fixed scope with agreed deliverables and timelines, and does not publish prices, so ask for a quote tied to the directory sources, clusters, applications and database platform you actually run.

Questions platform teams ask before choosing Keycloak or Dex

Can Dex do SAML safely for enterprise apps?

Not for most enterprise SAML use cases, and the risk comes from the project itself. Dex's README marks its SAML 2.0 connector as unmaintained and warns that it is likely vulnerable to authentication bypasses, even though the LDAP and GitHub connectors are marked stable. The README also explains that Dex issues no refresh token after a SAML login, which matters for clients such as kubectl that need offline access. If an application requires SAML as a service provider, a full identity provider such as Keycloak, which supports SAML 2.0 natively, is the safer path. Ask your security team to review the current Dex connector status in the README before any decision.

Does Keycloak replace an existing LDAP or Active Directory?

No. Keycloak does not replace a directory; it reads from one. Keycloak federates users from LDAP or Active Directory, so passwords and group memberships can stay where they are while Keycloak handles single sign-on and token issuance for applications. Dex also defers to LDAP, so this part of the answer is similar for both. The difference is that Keycloak can also hold its own users and brokers logins to external OIDC or SAML providers. Confirm with your directory team whether you need to write back to the directory, because Keycloak's federation is primarily a read path, and whether any legacy applications need LDAP directly, which would require a separate directory service.

What does running Keycloak need from our team?

Running Keycloak in production needs a platform team that can operate a relational database, a clustered Java service and an upgrade process. Keycloak requires a supported production database, such as PostgreSQL 14 to 18, and its default dev-file database is not suitable for production. Its high availability designs need a synchronously replicated database. On Kubernetes, the Keycloak Operator is installed through Operator Lifecycle Manager or kubectl, and the Operator documentation strongly recommends manual approval mode for updates. Keycloak also documents four minor releases a year, with breaking changes in minor releases opt-in. Dex, by contrast, is a single static Go binary with optional storage, so its operating footprint is much smaller. Confirm with your team who will own database backups, upgrades and monitoring.

Can we start with Dex and move to Keycloak later?

Yes, but plan the migration as a real project, not a configuration change. Dex owns no user state, so its users and sessions live in the identity providers behind it, which makes the front door easier to replace than a platform that holds passwords. The work is in the clients: every application or cluster that points at Dex's OIDC issuer must be repointed, redirect URIs and client secrets recreated in Keycloak, and any Kubernetes API server flags updated. Any MFA, group mapping or claim logic built in Dex must be rebuilt in Keycloak. If you expect to need SAML or offline kubectl access soon, it is usually cheaper to start with Keycloak. Ask for a written inventory of clients and claims before committing to either path.

How long does an implementation take and what drives it?

The timeline depends on scope, and no fixed duration applies across environments. The main drivers are the number of applications and clients to onboard, the directories and upstream identity providers to connect, the database and high availability design, and whether Kubernetes access or SAML integrations are included. A Dex deployment with a few upstream connectors on one cluster is a smaller piece of work than a Keycloak deployment with realms, SAML clients, federation and a multi-site design. Most DeployOpen engagements are fixed-scope, so scope, deliverables and timelines are agreed in writing before work starts. Ask for the timeline to be tied to a written list of integrations and environments.

Can we do this ourselves or should we hire help?

A team with Kubernetes and identity experience can run Dex for a narrow OIDC use case, such as kubectl sign-in through an existing LDAP or GitHub login. Keycloak is harder to run well on your own for the first time, because the database design, clustering, Operator upgrade path and realm configuration all affect security and availability. Outside help is most useful for scoping the architecture, hardening the deployment, building the integrations and producing the documentation and evidence your compliance reviewers will ask for. DeployOpen plans, implements, hardens, backs up, upgrades and documents self-hosted platforms in your own infrastructure, and offers ongoing support as a retainer. Confirm the skills your team already has before deciding.

How DeployOpen helps choose, implement or migrate

DeployOpen plans, implements, integrates, hardens and documents self-hosted open-source platforms inside your own infrastructure, so the Keycloak vs Dex decision is tested against your real sign-in paths, clusters and user sources before anything is built. We work from a written scope, and the deliverables reflect the choice you make.

How we scope

We inventory which applications, kubectl users and API servers need sign-in, and which user sources they draw from.
We confirm whether Dex's connectors cover your upstreams, including whether SAML or offline kubectl access is required.
Engagements are fixed-scope, with scope, deliverables and timelines agreed in writing before work starts.

How we build

We deploy the chosen platform in your cloud account, data center or air-gapped network, with its database or storage configured.
We wire Kubernetes API server authentication or application OIDC and SAML clients, and test token refresh behavior for each.
We run security testing against the sign-in configuration and document the findings and remediation before handover.

How we hand over

We deliver architecture notes, configuration records, runbooks for upgrades and backups, and the decision record behind the choice.
We document how to add a connector, client or realm, so your platform team can extend the setup without rebuilding it.
We walk your engineers through operations and confirm the handover checklist against the written scope.

How we support

Ongoing support, upgrades and continuous security testing are available as retainers after handover.
We can plan upgrades around each platform's release cadence and confirm breaking changes before they reach production.
If you later need a migration from Dex to Keycloak, we scope it as a separate written engagement with its own deliverables.

Keycloak vs Dex