SSO for Your Homelab: Authentik vs Authelia

Authelia if what you want is a login gate in front of a dozen containers: one Go binary, configuration in YAML files, around 30–50MB of RAM. Authentik if what you want is an identity provider: a web UI, OIDC and SAML and LDAP, invitation flows, per-app icons on a user portal — at roughly 1GB of RAM and several more moving parts. Both support passkeys and TOTP. The deciding question is whether your apps will authenticate through your proxy or against your IdP, so start there.

Forward-auth vs OIDC, the mental model

Forward-auth is a proxy trick: before serving any request, your reverse proxy asks the auth server "is this session logged in?" and redirects to a login page if not. It protects anything — including apps with no auth support whatsoever — because the app never knows it's happening. The limit: the app also doesn't know who you are (beyond an optional Remote-User header some apps can consume), so there are no real per-user accounts inside it.

OIDC is the app-native route: the application itself redirects to your identity provider, gets back a signed identity, and creates a real user session with roles and preferences. It requires per-app configuration but gives you actual multi-user behaviour — your partner's Jellyseerr requests, your own Grafana dashboards.

A homelab needs both: OIDC for the apps that support it, forward-auth as a blanket over everything else.

The comparison

The philosophical split matters more than any row: Authelia is configuration-as-code you version alongside your compose files; Authentik is a product you administer. Both are honest choices, and each project's docs — authelia.com and docs.goauthentik.io — are unusually good by self-hosted standards.

Passkeys earn a sentence beyond their table row: both projects support WebAuthn as a second factor and as a passwordless first factor, and rolling passkeys out at the SSO layer means every app behind it inherits them at once — including software that will never implement WebAuthn itself. In my house the TOTP adoption rate among non-technical users was dismal; with passkeys it's total, which quietly makes centralised auth a security upgrade for the household rather than just a convenience.

Proxy integration in six lines

Forward-auth with Caddy and Authelia, per protected app:

jellyseerr.home.example.com {
    forward_auth authelia:9091 {
        uri /api/authz/forward-auth
        copy_headers Remote-User Remote-Groups Remote-Email
    }
    reverse_proxy jellyseerr:5055
}

Traefik and nginx have equivalent middleware; the pattern is identical. Authelia's access-control rules then decide policy per domain — bypass for public things, one_factor for low-stakes, two_factor for anything that can delete data. Setting those three tiers deliberately is where SSO stops being a login screen and starts being a security model. If you're still choosing the proxy itself, the reverse proxy comparison covers that decision.

Which apps speak OIDC natively

More than you'd guess in 2026: Grafana, Immich, Gitea and Forgejo, Nextcloud, Paperless-ngx, Jellyseerr, Open WebUI, Portainer, Proxmox — the list of significant self-hosted apps without OIDC support shrinks every year. Jellyfin needs a plugin. The stragglers and the deliberately auth-free (most dashboards, many admin UIs) are what forward-auth is for. My split ended up around 60/40 OIDC-to-forward-auth across ~25 services.

Recovery planning: the section people skip and regret

Centralising auth means centralising failure. When the IdP is down, everything is down, including possibly your ability to fix it. Four rules that cost little and save the day:

• Keep one break-glass local admin account on critical apps (Proxmox, your NAS, Grafana), stored in your password manager, tested quarterly.
• Never put your IdP's own admin interface solely behind itself, and never protect the tools you'd use to repair it (container UI, docs) with the thing being repaired.
• Back up the auth layer like a database, because it is one: Authelia's YAML and its SQLite/Postgres storage; Authentik's Postgres plus an exported blueprint. An IdP restore that misses TOTP secrets logs the whole household out.
• Enrol two passkeys or TOTP devices per user where it matters. Phones fall in lakes.

And monitor the IdP from outside the SSO perimeter — an uptime check that requires logging in through the thing it's checking is a circular dependency wearing a dashboard.

What I'd do

Starting from zero with a git-managed compose homelab: Authelia. It's a YAML file next to your proxy config, it does forward-auth cleanly and OIDC well enough for the common apps, and its resource cost rounds to free. Move to Authentik when you hit a concrete wall — SAML-only software, invitation-based onboarding for non-technical family, LDAP for apps that speak nothing else, or simply wanting a portal page you can hand to your household. Migrating later is tedious (reconfigure each OIDC app) but not destructive. What I wouldn't do is run either without the recovery section above in place first; an SSO deployment's first real test is the day it breaks, and you want to have scheduled that test yourself.