Keycloak vs authentik vs Authelia: What to Self-Host

These three projects get compared constantly, and the comparison is usually framed as if they were three implementations of the same thing. They are not. One is a full identity provider designed for enterprise federation, one is a full identity provider designed around configurable login flows and an application proxy, and one is an authentication layer that extends a reverse proxy. Choosing between them is mostly a question of which of those three shapes matches the problem.

What follows is a comparison drawn from each project’s own documentation. No deployment of any of the three was benchmarked to write it, and where a project does not publish a figure, that is stated rather than filled in with an estimate.

What Each One Actually Is

Keycloak is an identity and access management server. It issues OAuth 2.0 and OpenID Connect tokens, speaks SAML, federates against LDAP and Active Directory, brokers to external identity providers, and manages users, roles, groups, and clients inside isolated realms. It runs on the JVM and requires a relational database. The concepts that structure it are covered in Keycloak realms, clients and token design fundamentals.

authentik is also a full identity provider, with its own take on the problem. Its documented architecture is a server container made of two sub-components: a core that “handles most of authentik’s logic, such as API requests, flow executions, any kind of SSO requests, etc.” and an embedded outpost that “allows using Proxy providers without deploying a separate outpost”. Alongside it sits a worker container, which “executes background tasks, such as sending emails, the event notification system”, and PostgreSQL, which authentik “uses to store all of its configuration and other data (excluding uploaded files)”. The outpost concept is the distinguishing piece: it lets authentik put authentication in front of applications that cannot speak a modern protocol themselves.

Authelia is described by its own documentation as “a 2FA & SSO authentication server which is dedicated to the security of applications and users”. The framing matters. It is designed to sit alongside a reverse proxy and answer the proxy’s authorization subrequest, providing multiple two-factor methods, identity verification for second-factor device registration, self-service password reset, and account lockout after excessive login attempts. Its first-factor backend is one of two documented options, LDAP, where “users are stored in remote servers like OpenLDAP, OpenDJ, FreeIPA, or Microsoft Active Directory”, or a file, where “users are stored in YAML file with a hashed version of their password”. Its storage backends are SQLite (configured as local), PostgreSQL and MySQL.

The one-line distinction: Keycloak and authentik are identity providers that can also protect applications; Authelia is an authentication gateway that has grown identity-provider features.

Comparison at a Glance

	Keycloak	authentik	Authelia
Primary shape	Enterprise IdP	IdP with application proxy	Reverse-proxy auth companion
Runtime	JVM (Quarkus)	Python/Go, server + worker	Single Go binary
Required datastore	Relational database	PostgreSQL	SQLite, PostgreSQL or MySQL
OIDC provider	Yes	Yes	Yes (OpenID Connect 1.0)
SAML	Yes	Yes	Not documented as a provider
LDAP/AD federation	Yes	Yes	Yes, as a user backend
Forward auth for legacy apps	Via proxy integrations	Yes, via outposts	Core use case
Realm-style isolation	Realms	No direct equivalent	No
Documented minimum host	2 GB container limit recommended	2 CPU cores, 2 GB RAM	Not published

Read the last row carefully. The Keycloak figure is a recommended container memory limit from its sizing guidance, the authentik figure is a documented host requirement of “a host with at least 2 CPU cores and 2 GB of RAM”, and Authelia does not publish a hardware figure in the pages cited. These are not measured against one another and should not be treated as a benchmark.

Where Each One Wins

Choose Keycloak when federation and standards coverage are the requirement

If the deployment has to interoperate with an existing Active Directory, broker to a customer’s own identity provider, issue SAML assertions to an application vendor that only speaks SAML, or separate populations of users into isolated namespaces, Keycloak covers all of it in one server. The realm model is a real multi-tenancy boundary rather than a naming convention.

The cost is operational weight. It is a JVM application with a real database dependency, distributed caches whose behaviour you need to understand, and a hostname and proxy configuration that must be right before anything works. That last point is the most common early failure, and it is covered in Keycloak hostname and proxy errors.

Choose authentik when you need to protect applications that do not speak a protocol

The outpost model is authentik’s genuine differentiator. A proxy provider can front an application that has no authentication of its own, and the embedded outpost means you do not have to deploy separate components to start. For an environment that is a mix of modern OIDC applications and older internal tools with no auth story, that is a meaningful reduction in moving parts.

The tradeoff is a two-container architecture plus PostgreSQL, and a background worker that has to be healthy for scheduled work, notifications, and email to function. It is not a single process.

Choose Authelia when the reverse proxy is already the front door

If everything in the environment already sits behind one reverse proxy and the requirement is “make people authenticate before they reach any of this, with a second factor”, Authelia is the smallest thing that does the job properly. A single Go binary, a file or LDAP user backend, and SQLite storage will run a household or small team deployment with very little to operate.

The limits show up when the requirement grows past the proxy. There is no realm-style tenancy boundary, SAML is not documented as a provider capability, and the user management story is deliberately thin because the user store is expected to live elsewhere.

The Decisions That Actually Separate Them

Do you need to be an identity provider for third parties? If another organisation’s application needs to trust your tokens or assertions, you want Keycloak or authentik. Standards coverage and key management are the whole job at that point.

Is your user store already authoritative somewhere else? All three read LDAP. Only Keycloak and authentik will also own users natively at scale with self-service registration, and only Keycloak exposes the import-versus-read-through decision explicitly, which matters because it determines whether attribute writes flow back to the directory.

How many applications cannot be modified? Every application that cannot be given an OIDC client is an argument for a proxy-based approach, which favours authentik’s outposts or Authelia’s forward auth. Keycloak can be placed behind a proxy that does the same thing, but the integration is assembled rather than built in.

What is the operational budget? Keycloak’s documented sizing baseline is “1250 MB of RAM” for a pod including realm caches and 10,000 cached sessions, and its container image defaults to a heap of 70 percent of the container limit. That is not large for a server, but it is the largest of the three and it comes with database sizing obligations. If capacity is the deciding factor, Keycloak memory usage and heap sizing works through the arithmetic, and the sizing calculator will run the numbers for a given login rate.

How many people operate it? A single Go binary that one person fully understands is a better outcome than a correctly-architected cluster that nobody can debug at 3am. This is not a technical criterion and it is usually the decisive one.

Migration Is Not Symmetrical

Moving between these is easier in some directions than others.

Applications that authenticate through OIDC move between any of the three with a configuration change: new issuer, new client ID and secret, new redirect URI. That part is genuinely portable, which is the point of the standard.

What does not move is everything around the protocol. Keycloak’s authentication flows, required actions, protocol mappers, and role model have no direct equivalent in the other two. authentik’s flow and stage model is likewise its own design. Authelia’s access control rules are expressed against proxy paths, a concept the other two do not share. Password hashes may or may not be portable depending on the algorithms configured on both ends, and if they are not, the migration includes a password reset for every user.

Plan a migration around three artefacts: the client registrations, the user store, and the authorization rules. Only the first is portable in any real sense.

A Reasonable Default

For a small self-hosted environment behind one reverse proxy, with no external federation requirement, Authelia does the job with the least to operate.

For a mixed environment with legacy internal applications that need to be fronted, authentik’s outposts remove work that would otherwise be assembled by hand.

For anything that must federate with an existing directory, broker external identity providers, serve SAML, or maintain separate user populations under one server, Keycloak is the one built for that shape, and the operational cost is the price of that coverage rather than incidental complexity. If that is the direction, start with realm and client design, because the realm and client decisions made in week one are the ones that are hardest to reverse later.