Self-hosted identity in 2026: an ecosystem map of Keycloak, authentik, and ZITADEL by where the control plane burden lives

A hardware security key fits this article because every identity control plane eventually has to cash out at the last mile of login, multi-factor authentication, and session issuance.

Most self-hosted identity comparisons start in the wrong place. Teams open a feature grid and ask which project speaks OIDC, SAML, SCIM, LDAP, passkeys, or social login. Those questions matter, but they usually do not decide whether the system will feel clean six months later. The expensive part of identity is not protocol vocabulary. It is where the operating burden lands once real applications, delegated admins, reverse proxies, and awkward edge cases show up.

That is why Keycloak, authentik, and ZITADEL are easiest to read as three different control-plane shapes rather than three brands chasing the same box checklist. Keycloak concentrates identity into a central realm-and-client machine with mature brokering and federation, then expects you to run it behind a reverse proxy and think clearly about clustered session behavior.[1][2] authentik presents itself as a flexible IdP and SSO platform, then pushes part of its logic outward through outposts so proxy, LDAP, RADIUS, and RAC integrations can live closer to the applications that need them.[3][4] ZITADEL starts from a different center entirely: instance, organization, and project are first-class structural layers, so customer and tenant boundaries sit inside the product model from the beginning.[6][7][8]

The high-signal question, then, is simple: when identity stops being a pilot and becomes a recurring platform responsibility, do you want that responsibility centered in one heavyweight admin plane, distributed toward app-adjacent connectors, or modeled as multi-tenant hierarchy from day one?

Image context: the cover photograph shows a hardware security key, which is a useful reminder that identity architecture only becomes real when policy reaches the last mile of authentication and session issuance, not when the admin console still looks tidy on paper.[10]

1. Keycloak is the central standardizer

Keycloak still makes the most sense when the platform team wants one large, legible center. Its administration guide is explicit about the core concepts: realms, clients, roles, groups, identity brokering, and user federation are the main operating vocabulary.[1] That shape rewards teams that want many applications to inherit policy from one place and are comfortable treating identity as a shared platform service rather than as something every product team customizes independently.

The advantage of that center-heavy model is maturity. Keycloak can broker external OpenID Connect or SAML identity providers, sync users from LDAP and Active Directory, and expose a broad administrative surface through the same system.[1] If your environment already has enterprise directories, multiple upstream identity providers, or a large internal estate of clients that need predictable protocol handling, that breadth matters. The point is not that Keycloak has "more features." The point is that it is built to normalize many identity relationships inside one server-oriented operating model.

The cost shows up in operations. Keycloak's reverse-proxy guide assumes distributed environments frequently sit behind a reverse proxy, API gateway, or load balancer, and it explicitly discusses ports, hostname configuration, and sticky sessions in clustered deployments.[2] In other words, Keycloak is rarely just "turn it on and go." It works best when there is a platform team willing to own the central service as infrastructure: ingress, proxy headers, cache behavior, and session topology are all part of the product choice, not housekeeping after the fact.[2]

Put differently, Keycloak is strongest when the sentence "we need one identity center for many apps" is already true inside your organization.

2. authentik is the flexibility-first system for messy estates

authentik's docs describe it as an IdP and SSO platform built with security, flexibility, and versatility in mind.[3] That positioning is not marketing fluff. The product shape is genuinely different from Keycloak's. Rather than forcing every integration to terminate at one central server boundary, authentik can move provider logic into outposts, which are deployable services that connect back to the authentik API.[4]

That design matters because real identity estates are messy. Some applications want proxy auth in front of legacy web apps. Some want LDAP. Some want RADIUS. Some need remote access control. authentik's outposts exist exactly for those situations: the docs say LDAP, Proxy, RADIUS, and RAC providers require an outpost, and the reason given is flexibility, speed, and moving provider logic out of authentik Core.[4] That is a materially different control-plane bet from Keycloak. Instead of asking every awkward app to conform to one central surface, authentik is willing to station small identity workers closer to the place where protocol mismatch happens.

This is why authentik often feels better than its competitors in heterogeneous estates with self-hosted apps, reverse-proxy patterns, or security teams that want strong login policy without rewriting every target service. It is not only an identity directory. It is also a policy-and-connector system for apps that were never especially identity-native.

The boundary is just as important. authentik does have a tenancy feature, but its own docs label that feature alpha and warn that it should not be confused with brands from earlier versions.[5] The docs also describe tenancy as allowing an operator to create multiple tenants with separate install IDs and licenses.[5] That is useful, but it is not the same thing as saying multi-tenant B2B structure is the stable center of the product. So if your main requirement is "every customer gets a clean org boundary with delegated management built into the primary model," authentik is not the safest first bet. Its strongest lane is flexibility around awkward apps and policy surface, not tenant hierarchy as the foundational abstraction.

3. ZITADEL is the tenant-forward identity system

ZITADEL becomes easiest to understand once you stop comparing it to a generic SSO server and start reading it as identity infrastructure with hierarchy built in. Its docs place instance, organization, and project at the center of the model.[6][7][8] That changes the selection logic immediately.

The organization page is the clearest signal. It says organizations separate settings and data from one another and supports delegation so organizations can grant rights to self-manage parts of the IAM setup; it even frames the B2B case directly, where an organization represents a business partner with its own branding, access settings, or federated login providers.[7] That is not an add-on interpretation. It is a statement about what the system believes an identity boundary is.

The project layer sharpens the picture. ZITADEL's project docs say multiple projects can exist within an organization, and that applications inside a project share roles, grants, and role assignments.[8] That gives platform teams a crisp way to model "customer," "application family," and "authorization surface" without stretching one realm or one brand concept until it breaks. If you sell software to other organizations, delegate administration, or need customer-specific identity settings without re-inventing tenant modeling in your own app, this structure is a major advantage.[7][8]

The operating surface is also more opinionated than it first appears. ZITADEL's Kubernetes guide ships with an optional PostgreSQL subchart for quick starts, but the same guide also expects an ingress controller, external domain settings, secret management, and multi-replica production hardening.[9] So ZITADEL is not "serverless identity magic" when self-hosted. It is simply opinionated about what the hierarchy should be once the system is running.

That makes ZITADEL strongest when the sentence inside your organization is not "we need one shared login center," but "we need identity boundaries that line up with customers, organizations, and delegated admins."

4. A practical decision map

Use this filter before you get seduced by protocol breadth.

Choose Keycloak first when:

you want one central identity service for a large internal application estate
LDAP, Active Directory, and upstream identity brokering are core requirements rather than edge cases[1]
your platform team is prepared to own reverse proxy, clustering, and central service operations as part of the decision[2]

Choose authentik first when:

your application estate is heterogeneous and awkward, with proxy-auth, LDAP, or RADIUS-shaped integration problems[4]
login policy flexibility matters more than tenant hierarchy purity[3][5]
you want the option to deploy identity-adjacent components closer to the apps that force exceptions[4]

Choose ZITADEL first when:

B2B structure, delegated administration, and organization boundaries are the center of the problem[7]
you need applications and roles grouped cleanly under project-level authorization surfaces[8]
you are comfortable adopting a more opinionated hierarchy because it matches your business model[6][7][8]

5. The mistake to avoid

The most common mistake is to treat all three as interchangeable "open-source Auth0 alternatives." That collapses three different operating models into one shopping category.

Keycloak is the best fit when the platform team wants to standardize identity centrally and absorb the infrastructure cost that comes with that.[1][2] authentik is the best fit when the real burden lies in adapting messy app estates and keeping policy flexible at the edges.[3][4][5] ZITADEL is the best fit when customer and organization boundaries are not secondary concerns but the main structural truth of the system.[6][7][8][9]

One falsifier is worth naming. If your environment is small, your apps are modern, and your main need is just one OIDC provider plus a handful of social logins, then the architectural distinctions above may matter less than deployment simplicity. But once delegated administration, legacy protocols, proxy auth, or customer hierarchy enters the picture, these three products stop looking interchangeable very quickly.

cronfeed.work