Authelia vs authentik

These two get compared because they sit in the same box on every homelab chart, but they are answering different questions.

Authelia is a gate. Your reverse proxy stops each request, asks Authelia whether this browser session is allowed, and gets a yes or no. It is one Go binary, about 35 MB idle, and its configuration is a YAML file you can print out.

authentik is an identity provider. Applications redirect to it, it authenticates the user, and it hands back an OIDC token or a SAML assertion that the application uses to create its own session. It also happens to do forward auth, which is why the comparison exists at all. It costs three containers, PostgreSQL and roughly a gigabyte before anyone logs in.

The choice is not "lightweight versus full featured". It is whether your apps can log a user in from a token, or whether you are papering over apps that cannot.

Read the memory row and the container count first#

Two rows in this table decide most installs: idle RAM and container count. The 30x memory difference is real, and so is the difference between one process and three services around a database when you come to restore them.

Authelia is ops load 3 despite being a single binary, because its config is coupled tightly to your reverse proxy and 4.38 rewrote both halves at once. authentik is ops load 4: calendar-versioned releases roughly monthly, breaking changes inside ordinary releases, and a restore that needs the PostgreSQL dump and the original secret key together.

What forward auth does not do#

This is the thing that a feature comparison never says out loud. Forward auth gates the request. It does not log you into the application.

The flow is: browser asks for paperless.example.com, proxy pauses and calls Authelia's /api/authz/forward-auth endpoint, Authelia says yes because there is a valid session cookie, proxy forwards the request with Remote-User: alice and Remote-Groups: admins attached. That is the entire mechanism.

If the application behind it does not read those headers, alice now sees the application's own login page. She has authenticated twice and gained nothing except a second factor in front. Some apps do read them, Paperless-ngx and Grafana among them, and for those there is exactly one login. Many do not, and there is no way to tell from the outside except to try it.

The second half of the problem is everything that is not a browser. Mobile apps, WebDAV clients, API tokens, Jellyfin on a television: none of them can complete an interactive login at a portal. The fix is a bypass rule, and every bypass is an unauthenticated hole:

access_control:
  default_policy: deny
  rules:
    - domain: nextcloud.example.com
      resources: ["^/remote.php/dav.*"]
      policy: bypass
    - domain: nextcloud.example.com
      policy: two_factor

Rules are first-match-wins and ordered. Put that bypass one line higher, with no resources filter, and you have silently disabled two-factor for the entire host. Audit the whole rule list, not just the rule you added last.

Where authentik earns its gigabyte#

authentik is the only tool in this category that covers all four integration styles from one server:

• OIDC for apps that speak it: Immich, Grafana, Forgejo, Nextcloud.
• SAML for the one stubborn application that speaks nothing else.
• An LDAP outpost, so apps that only bind against a directory can bind against authentik.
• A proxy provider with an embedded outpost, which is forward auth, so apps with no authentication at all still get a gate.

If you need two or more of those, Authelia cannot do the job. It ships no SAML provider and it does not serve LDAP; it consumes LDAP as a user source. That is the clean disqualifier, and it decides more installs than memory does.

The other thing authentik gives you is an event log you can search: who logged into what, which flow executed, which policy denied. Authelia's audit trail is the regulation table and your proxy logs.

Where Authelia is the better engineering decision#

Authelia has never shipped a 1.0. It is on 4.39.22 as of September 2026, and that version number is a leftover from 2019 rather than a warning label. The forward-auth half has been dependable for years.

Its OIDC provider is a different matter and you should be precise about it. It is OpenID Certified, and the project still labels it beta: currently Beta 8, targeted at 4.40.0, with breaking changes that have landed inside minor releases. For a homelab issuing tokens to five apps, that means reading release notes before you upgrade, not avoiding it.

What you get in return is a system you can hold in your head. One process. One configuration.yml. Four secrets you generate yourself. Backup is the SQLite file plus the encryption key. Compare that with authentik's restore, which is a pg_dump, the identical AUTHENTIK_SECRET_KEY, the media volume, and then waiting for outposts to reconnect.

Two Authelia defaults will catch you:

• Sessions are in memory by default. Every restart, every image pull, every host reboot signs out every user, including anyone mid-way through TOTP enrollment. Adding Redis fixes it and turns your one container into two.
• Cookie domains obey the Public Suffix List. You cannot share a session cookie between example.duckdns.org and example-auth.duckdns.org. If you are on free dynamic DNS, this is the wall you hit first, and the only fix is a registrable domain of your own. DNS for self-hosters covers getting one properly.

Upgrades: both have a cliff behind you#

Authelia's is 4.38. Coming from 4.37 or earlier is a config rewrite, not a tag bump: session.domain and default_redirection_url moved into a session.cookies array, remember_me_duration became remember_me, a mandatory authelia_url appeared, the OIDC issuer_private_key became a jwks array, and /api/verify was replaced by per-proxy endpoints with the rd parameter removed. Your reverse proxy snippet changes at the same moment, so plan for both halves being wrong at once.

authentik's cliffs are recent and there are two:

• 2025.10 removed Redis. Caching, embedded outpost sessions and websockets moved into PostgreSQL. Expect roughly 50 percent more database connections, which breaks an external Postgres with a conservative max_connections. Upgrade with --remove-orphans to clear the container you no longer need.
• 2026.8 made trusted proxy CIDRs mandatory. The server ignores X-Forwarded-* headers unless the connection comes from a network in AUTHENTIK_LISTEN__TRUSTED_PROXY_CIDRS. Miss it and every login appears to come from your reverse proxy, IP policies stop matching and the event log becomes useless. Set it before you pull the tag.

Licensing, precisely#

Authelia is Apache-2.0 throughout. No tiers, nothing gated.

authentik is MIT for the core and a separate Authentik Security license for everything under authentik/enterprise/, enforced at runtime by a subscription key covering your user count. What is behind that wall: Google Workspace and Microsoft Entra ID provisioning, RADIUS with EAP-TLS, client certificate authentication, detailed audit logging and CSV export. Nothing there matters for a household. It matters if you were planning to push users outward into a corporate directory.

Which one for your situation#

What to do next#

Before you install either, list your applications and mark each one as OIDC-capable, header-auth-capable, LDAP-only, or none of the above. That list picks the tool for you, and it takes twenty minutes. Single sign-on for self-hosters walks through doing it, The single sign-on gap has the numbers on how many self-hosted apps actually support anything, and Backups that actually restore covers the part that catches people out here: both of these hold a key outside the database, and a backup without it restores nothing.