Authelia vs Authentik: Choosing a Self-Hosted SSO You Won't Regret

There comes a moment in every homelab’s life when you realise you have a dozen logins. Grafana wants a password. So does Sonarr, and Radarr, and that Nextcloud instance, and the thing you spun up at 2am and have already forgotten the credentials for. Each one is its own little island of authentication, half of them reusing the same password because you’re only human, and exactly none of them have multi-factor authentication because configuring it twelve times sounded like a Tuesday you’d rather not have.

The fix is single sign-on (SSO): one login, sitting in front of everything, that the rest of your services trust. Log in once, and a session cookie carries you everywhere. Two open-source projects dominate this space for self-hosters: Authelia and Authentik. They solve the same problem from opposite ends, and picking the wrong one means either fighting YAML you didn’t need or babysitting a database you didn’t want.

Before going further, one honest caveat: SSO is a force multiplier in both directions. Done well, it gives you one strong, MFA-protected front door instead of a dozen weak ones, and that is a genuine security upgrade. Done badly — a weak master password, no second factor, a single login server with no recovery path — it concentrates all your risk behind one door and then leaves that door ajar. The decision below is not just “which is easier”; it is “which one will I actually keep configured correctly”, because the most secure SSO is the one you maintain rather than the one with the longest feature list.

The problem, and how forward-auth solves it

Most homelab services sit behind a reverse proxy already — Traefik, nginx, or Caddy. Forward-auth (also called auth-request) is a neat trick where, before the proxy serves a request, it phones a friend: “is this person allowed in?” That friend is your SSO server. If there’s no valid session, the user gets bounced to a login page; once they’re authenticated, the proxy lets the request through and remembers them.

The beauty is that the protected app needs no changes whatsoever. Sonarr doesn’t know or care that something is guarding its front door. This is how you put MFA in front of an application that has never heard of MFA.

Authelia: lightweight and config-as-code

Authelia is a single Go binary with a small memory footprint — it’ll happily run in well under 100MB of RAM. Everything is configured through a configuration.yml file. Users live in a flat file or an LDAP backend; sessions can be stored in memory or Redis; and access control is a list of rules you write by hand.

It does TOTP and WebAuthn for second factors, and its killer feature is per-rule policy. You decide which paths need one factor, two factors, or are public:

 1
 2
 3
 4
 5
 6
 7
 8
 9
10

access_control:
  default_policy: deny
  rules:
    - domain: 'grafana.example.com'
      policy: one_factor
    - domain: 'sonarr.example.com'
      policy: two_factor
      subject: 'group:media'
    - domain: 'public.example.com'
      policy: bypass

Wiring it into Traefik is a forward-auth middleware applied as a label:

1
2
3
4
5

labels:
  - "traefik.http.middlewares.authelia.forwardauth.address=http://authelia:9091/api/verify?rfc2616=true"
  - "traefik.http.middlewares.authelia.forwardauth.trustForwardHeader=true"
  - "traefik.http.middlewares.authelia.forwardauth.authResponseHeaders=Remote-User,Remote-Groups,Remote-Email"
  - "traefik.http.routers.sonarr.middlewares=authelia@docker"

What you don’t get is a pretty admin UI. There isn’t one. You edit YAML, restart, and move on. For people who keep their infrastructure in Git, that’s a feature: your entire auth policy is reviewable, version-controlled, and reproducible. For people who want to click buttons, it’s friction.

One thing worth flagging before you commit: Authelia’s configuration has churned across major versions. Session and storage settings have moved around, and the OIDC provider configuration in particular was reworked, so a configuration.yml you copied from a two-year-old blog post will not start a current release unchanged. Read the changelog before every upgrade — the project documents breaking changes clearly, but it does expect you to read them. Pin the image to a specific version rather than latest so an unattended pull never swaps the config schema out from under you at the worst possible moment.

Authentik: heavier, but a proper identity provider

Authentik is a different animal. It’s a Python/Django application with a worker process, a PostgreSQL database, and a Redis cache — so you’re looking at four or five containers and a few hundred megabytes of RAM minimum before you’ve authenticated anyone. In exchange, you get a full web admin UI and a genuine identity provider.

Where Authelia is mostly forward-auth, Authentik speaks the whole alphabet: OAuth2, OIDC, SAML, a proxy provider for the forward-auth use case, and an LDAP outpost so legacy apps can bind against it. If you want to log into a third-party SaaS app, or a self-hosted app that natively supports “Sign in with OIDC,” Authentik is built for exactly that. Authelia can do OIDC too, but Authentik makes it the centrepiece.

Its configuration model is flows and stages: a login flow is a sequence of steps (identification, password, MFA, consent) that you assemble and reorder in the UI. It’s powerful and flexible, and it has a learning curve. There’s a lot of UI to learn, and “where on earth is that setting” is a normal Tuesday for the first week.

The forward-auth wiring looks much like Authelia’s, but Authentik adds an outpost — a small companion process that does the actual proxying or LDAP bridging. For a Traefik forward-auth setup, the embedded outpost exposes an endpoint you point the middleware at:

1
2
3
4
5

labels:
  - "traefik.http.middlewares.authentik.forwardauth.address=http://authentik-server:9000/outpost.goauthentik.io/auth/traefik"
  - "traefik.http.middlewares.authentik.forwardauth.trustForwardHeader=true"
  - "traefik.http.middlewares.authentik.forwardauth.authResponseHeaders=X-authentik-username,X-authentik-groups,X-authentik-email"
  - "traefik.http.routers.sonarr.middlewares=authentik@docker"

The outpost concept is what lets Authentik front protocols Authelia simply does not speak. It is also a moving part Authelia does not have, which matters when something breaks.

Authentication that survives without a screen

A point both projects get right, and one worth raising because it bites people: think about what happens when the SSO is down. If everything sits behind one login server and that server is unreachable, you have locked yourself out of your own house. With Authelia I keep the config in Git and the binary trivially redeployable, so recovery is “start the container again.” With Authentik, recovery means the database is healthy too, which is one more thing that has to be true at 2am. Whichever you pick, keep one administrative path that does not depend on the SSO — direct access to the reverse proxy host, or a bypass rule for a recovery endpoint — so a broken auth server is an inconvenience, not a lockout. If you are leaning on SSO to also gate sensitive services, pair it with proper server monitoring so you find out the auth server is sick before your users do.

The trade-offs, honestly

• Footprint: Authelia sips resources; Authentik needs Postgres and Redis and won’t apologise for it.
• Config style: Authelia is YAML-in-Git; Authentik is point-and-click with an API underneath.
• Protocols: Both do forward-auth and OIDC. Authentik adds first-class SAML and an LDAP outpost.
• Maintenance: Authelia upgrades are “pull a new binary, mind the changelog.” Authentik upgrades carry a database, which means migrations, backups, and the occasional held breath.
• Recovery: if Authelia dies, restart the container and you are back. If Authentik dies, you also need a healthy Postgres before anyone can log in anywhere — a bigger surface to keep alive.

A useful way to decide is to imagine the post-mortem. Picture the worst case for each — the day your SSO server falls over and takes every protected service with it — and ask which recovery you would rather perform half-asleep. For Authelia that is “redeploy a stateless binary from a config in Git.” For Authentik it is “restore a database, reconcile migrations, and bring a worker and server back into agreement.” Neither is hard when everything is healthy; the question is which you trust yourself to execute when it is not. If that thought experiment makes you nervous about Authentik’s moving parts, that nervousness is data: it is telling you the footprint exceeds what you want to be responsible for, and you should pick the lighter tool even if its feature list is shorter.

Troubleshooting: the failures you will actually hit

Both tools fail in a small set of predictable ways, almost all of them about headers, cookies and clocks rather than the auth logic itself.

The redirect loop. You log in, land back on the login page, log in again, forever. Nine times out of ten this is a cookie-domain mismatch: the session cookie is scoped to example.com but you are accessing the app at a host that the cookie does not cover, so the proxy never sees a valid session. Make sure the SSO’s configured session domain is the parent of every protected hostname, and that you are using HTTPS consistently — a cookie marked Secure will silently vanish over plain HTTP.

The proxy isn’t forwarding the right headers. Forward-auth only works if the reverse proxy passes the original host, URI and protocol through to the SSO and then passes the auth response headers back to the app. A missing trustForwardHeader or a forgotten authResponseHeaders line produces a baffling “logged in but the app says I’m anonymous.” When in doubt, watch the SSO’s debug log while you make one request — it will tell you exactly which header it expected and did not get.

TOTP codes are rejected. If second-factor codes never work, check the clock. TOTP is time-based, so a host whose clock has drifted by more than thirty seconds will reject every code. Run NTP on the SSO host and the problem evaporates.

Authentik won’t start after an upgrade. This is almost always a pending database migration that failed, or a server and worker on mismatched versions. Check that both the server and worker containers are on the same tag, then read the migration logs. Take a database backup before every Authentik upgrade — the one time you skip it is the time the migration goes sideways. This is the resource tax made concrete, and it is why a stateless tool like Authelia is genuinely lower-stress to operate. If you are weighing this against other security infrastructure you self-host, the same “what does it cost me to keep running” question applies to heavier tools like a self-hosted SIEM.

The verdict

If your goal is to slap MFA and one login in front of a stack of self-hosted apps behind a reverse proxy, and you like your config in version control, pick Authelia. It’s the lower-maintenance, lower-footprint choice, and for the classic homelab it’s the right answer roughly nine times out of ten. I run it, I rarely think about it, and that’s the highest praise I can give a piece of authentication software.

If you need to be a real identity provider — SAML for some app that demands it, OIDC for half a dozen things, an LDAP outpost for the awkward legacy box, and you genuinely want a GUI to manage users and groups — pick Authentik. It does more because it is more, and on the day you need that breadth you’ll be glad you paid the resource tax.

Pick the smallest tool that solves your actual problem. Then enjoy logging in once and never seeing twelve login screens again.