Pocket ID vs Authelia vs Authentik: which SSO to pick for your homelab

You run fifteen services at home and you have fifteen separate logins. Search for a way to unify them and three names come back, usually quoted as if they were interchangeable: Pocket ID, Authelia and Authentik. They are not. They solve similar problems through incompatible mechanisms, and choosing wrong means finding out halfway through the install that the project you picked cannot protect half of what you own. Here are the three models, the numbers I verified against primary sources on 30 August 2026, and a recommendation per scenario.

Key takeaways

• The first decision is not which product you install. It is which mechanism you need: proxy-delegated authentication, a genuine OIDC identity provider, or full federation with SAML and LDAP.
• Pocket ID is a certified OpenID Connect provider that accepts passkeys only, ships as a single Go binary and demands HTTPS with no exceptions.
• Authelia was born as a companion to the reverse proxy; its OpenID Connect provider is certified and still carries a beta label.
• Authentik is the only one of the three with SAML, an LDAP endpoint, SCIM and RADIUS, and the only one that asks for PostgreSQL, Redis and 2 GB of RAM.
• The Authentik server image weighs 356.0 MB compressed against 25.6 MB for Authelia and 30.7 MB for Pocket ID.

Three different answers to the same problem

When someone says "I want SSO at home" they are usually asking for three things the industry solves along separate paths, and conflating them is the classic error in this comparison.

Proxy-delegated authentication, which the documentation calls forward auth, happens before the request ever reaches the application. The reverse proxy intercepts every request, asks an external service whether that user may pass, and either lets the request through or redirects to a login form. The protected application never learns any of this happened. That is why the mechanism works for Sonarr, for an old dashboard with no user model, for anything that will never implement an identity protocol. Traefik calls it ForwardAuth, nginx does it with auth_request and Caddy with forward_auth.

An OIDC identity provider is a different animal. Here the application takes part: it speaks OpenID Connect, redirects the user to the provider, receives a signed token back and builds its own session from the user and groups inside it. Far cleaner, because each application keeps its own notion of permissions, but it requires the application to ship OIDC support. Jellyfin, Gitea, Immich, Nextcloud and Grafana have it. Half the self-hosted catalogue does not.

Full federation is enterprise territory: SAML 2.0 for older applications, an LDAP endpoint so some appliance can query users as if it were talking to a directory, SCIM to create and remove accounts in external services, RADIUS for wifi and VPN. Almost nobody needs this at home, right up until the day they do.

Which protocol each one speaks

This table settles most of the decision. Everything else is nuance.

Pocket ID: an OIDC provider that only understands passkeys

Pocket ID is the youngest of the three: the repository was created on 11 August 2024 and already has 9,057 stars. Version v2.14.0 landed on 18 August 2026, and since v2.7.0 on 11 May the project has shipped seven minor releases, so the cadence runs around one every two weeks. It ships as a single Go binary or a container image, stores data in SQLite by default, and switches to PostgreSQL by changing the connection string.

What defines it is the absence of passwords. There is no password field on any screen: you sign in with a passkey held in your browser, on your phone, in a password manager or on a hardware key. If a user loses access, an administrator issues a temporary login code from the panel or from the command line. That is the whole model.

That model also produces its hardest constraint, worth understanding before you install anything: "Pocket ID requires a secure context, meaning it must be served over HTTPS. This is necessary because Pocket ID uses the WebAuthn API", says the installation documentation^[1]. The browser WebAuthn API refuses any origin that is not secure, localhost aside. On an internal IP over plain HTTP, Pocket ID simply does not work.

The second constraint is one of scope, and the project states it plainly in its proxy services guide: "The goal of Pocket ID is to function exclusively as an OIDC provider. As such, we don’t have a built-in proxy provider". That is a design decision, not a gap awaiting a fix. To protect something that does not speak OIDC you put OAuth2 Proxy, Caddy with the caddy-security plugin, or a Traefik plugin in front, and that extra piece becomes yours to run. In exchange, the integration catalogue is unusually well tended: I counted 96 per-application guides in the documentation sitemap on 30 August 2026. The full walkthrough lives in the Pocket ID with passkeys install guide.

Authelia: YAML files, forward auth and a permanently beta OIDC

Authelia has been going since December 2016 and is both the oldest and the most starred of the trio, at 28,742 stars. Its own description places it precisely: "an open-source authentication and authorization server providing two-factor authentication and single sign-on (SSO) for your applications via a web portal. It acts as a companion for reverse proxies by allowing, denying, or redirecting requests". A companion to the proxy, not a replacement for it.

That is its strength. It integrates with Traefik through ForwardAuth, nginx through auth_request, Caddy through forward_auth, and also with HAProxy, Envoy, Skipper, SWAG, NGINX Proxy Manager and several Kubernetes ingress controllers. Access rules are written per subdomain, user, group, path, method and network, and each rule picks one factor or two. For a homelab full of services with no login of their own, this model covers in ten lines what OIDC would need an intermediate piece per application to achieve.

The OpenID Connect provider exists and is certified to the Basic, Implicit, Hybrid, Form Post and Config profiles, but the project qualifies its status in the README: "While this offering is still effectively on the roadmap as a beta it’s very comprehensive and well implemented already". The integration documentation repeats the open-beta label. It works and plenty of people run it in production; you just want to know what the label says. SAML 2.0, by contrast, neither exists nor is being built: it sits in the planning section of the roadmap.

On factors, Authelia accepts FIDO2 and WebAuthn keys, TOTP codes and Duo push notifications, and it has an enable_passkey_login option that its documentation describes this way: "Enables login via a Passkey instead of a username and password. This login only counts as a single factor". The passkey replaces the username and password, so if you want two factors you must require something else on top.

The price is the absence of an admin interface. Everything is configured in a YAML file plus environment variables, validated with authelia config validate, and applied by restarting the service. Users live in another YAML file or in an external LDAP server. If you keep your infrastructure in Git that is a virtue. If you want to add a family member from your phone, less so.

Authentik: the complete identity provider and what it costs

Authentik introduces itself as "an open-source Identity Provider (IdP) for modern SSO. It supports SAML, OAuth2/OIDC, LDAP, RADIUS, and more, designed for self-hosting from small labs to large production clusters". The provider list is by far the longest: OAuth2 and OIDC, SAML, LDAP, SCIM, RADIUS, a proxy provider with forward auth, remote access, WS-Federation, Microsoft Entra ID and Google Workspace. It is written in Python, has 25,244 stars, and version 2026.8.0 shipped on 18 August 2026 after seven release candidates between 3 and 10 August.

Its genuine difference from the other two is not the protocol list but the flow engine. In Authentik a login is an editable sequence of stages: identification, password, second factor, consent, legal notice, whatever you assemble. You can send one group through a passkey and another through an approval form. That flexibility is why people choose it and also why they get stuck: the learning curve is in understanding flows, stages, policies and bindings, not in starting the container. The basic route is covered in the Authentik install guide.

The proxy, LDAP, RADIUS and remote-access providers do not run inside the main server: they need an outpost, which the documentation defines as "a single deployment of an authentik component, essentially a service, that can be deployed anywhere that allows for a connection to the authentik API". In practice that means one more container per role. And the documented minimum install asks for "a host with at least 2 CPU cores and 2 GB of RAM", with PostgreSQL and Redis always present.

What each one costs to run

I measured the image sizes myself on 30 August 2026 by reading the container registry manifests and summing the compressed size of the amd64 layers. These are not third-party estimates.

The Authentik image is 11.6 times the size of the Pocket ID one and 13.9 times the Authelia one, and that is before counting PostgreSQL and Redis. On a mini PC with 4 GB shared across twenty containers, that difference shows up at boot and on every upgrade. On a box with 32 GB you will never notice it.

The other dimension of cost is configuration surface. Authelia keeps everything in a YAML file you can read end to end in ten minutes and version in Git. Pocket ID configures itself almost entirely through environment variables plus a small web UI. Authentik has a full admin panel and, with it, far more ways to misconfigure something without realising.

What happens when the identity provider goes down

This is the scenario people discover the hard way, and the behaviour changes radically depending on which mechanism you picked.

With proxy-delegated authentication, the outage is total and immediate. The proxy asks Authelia or the Authentik outpost before every request; if nobody answers, the proxy denies, and everything behind it becomes unreachable, including the things you only wanted to keep half an eye on. A failure of the identity service becomes a failure of the whole homelab.

With plain OIDC the outage is softer. Each application keeps its own session after the first sign-in, so if Pocket ID falls over, users already logged in keep working until each service’s local session expires. What breaks is new logins. At three in the morning that is a meaningful difference.

Then there is the personal lockout, which is the failure people actually hit: losing the passkey, switching phones, wiping a laptop. Each project has its own escape hatch, and you want to test it on install day rather than on panic day:

docker compose exec pocket-id /app/pocket-id one-time-access-token admin@example.com
docker compose run --rm server create_recovery_key 10 akadmin
docker compose exec authelia authelia crypto hash generate argon2 --password 'newone'

The first line belongs to Pocket ID and returns a temporary login code for the named user. The second belongs to Authentik and creates a link valid for 10 minutes for the akadmin account; the documentation describes the result as one that "will output a link that can be used to instantly gain access to authentik as the user specified above". The third is the closest thing Authelia has, since it ships no recovery command: it generates a password hash you paste into the users file before restarting the service. Keep a second administrator passkey somewhere other than your usual device too, for instance in your self-hosted password manager, which is what Vaultwarden is for. And if you go the proxy route, have a bypass rule ready that you can enable without going through the login portal.

Migrating between them

Bad news first: users and groups migrate, credentials do not. A passkey is a key pair bound to the relying party identifier, meaning the provider’s domain, and its public key lives in the old provider’s database. TOTP secrets are bound to the issuer. Switching projects means every person re-registers their second factor. In a household of four that is an afternoon; in a group of twenty, plan for it.

The application side depends on the jump. Moving from one OIDC provider to another means changing the issuer URL, the client ID and the secret in each application, and little else. Moving from forward auth to OIDC means touching every application one by one to enable its own login, and some of them do not have one. Going the other way, from OIDC to a proxy, you lose the notion of groups inside each application and end up managing permissions in two places.

What works in practice is not migrating in one go. Stand the new provider up on a different subdomain, move two or three low-stakes services, live with both for a week, and only then move the rest.

Which one to choose for your case

Choose Pocket ID if everything you self-host speaks OIDC, you already have real domain names and valid certificates, and you fancy getting rid of passwords. It has the fewest moving parts and is the most pleasant to use daily. Rule it out if you need to protect applications with no login of their own and you do not want to run an OAuth2 Proxy in front.

Choose Authelia if most of your services have no decent authentication, you already run Traefik, nginx or Caddy, and a YAML file does not scare you. It is the best answer to the real homelab problem, which is almost never enterprise federation and almost always "this should not be open to the internet".

Choose Authentik if you need SAML, an LDAP endpoint for something that only understands directories, RADIUS for wifi, SCIM provisioning, or a proper admin interface because you will not be the one creating accounts. Also if your homelab is really a practice lab for what you do at work.

There is a fourth legitimate answer: Pocket ID or Authelia as the OIDC provider, with OAuth2 Proxy in front of the four stubborn applications that cannot authenticate. Less elegant on paper, lighter on the machine.

Frequently asked questions

Can I run Pocket ID over HTTP on my local network?

No. The WebAuthn API requires a secure context and makes an exception only for localhost, so passkeys never get registered. You need HTTPS with a valid certificate, whether from a public authority or from an internal one installed on all your devices.

Is Authelia less secure because its OIDC is in beta?

The label is about interface stability commitments, not known holes. Authelia is certified by the OpenID Foundation to five profiles, which means passing a conformance suite. What the label implies is that some configuration detail may change between releases.

Is Authentik worth it for ten services at home?

Only if you need a protocol the other two lack, or if you will be managing users other than yourself. For ten services and a single administrator, the cost of maintaining PostgreSQL, Redis, the server, the worker and the outposts does not pay for itself.

Conclusion

This comparison resolves long before you install anything. If your services speak OpenID Connect, a small OIDC provider like Pocket ID gives you the best day to day. If they do not, Authelia’s proxy-delegated authentication solves the actual problem in a 25.6 MB image and one configuration file. And if you need SAML, LDAP or RADIUS, Authentik is the only answer, with its four containers and its 2 GB of RAM. Test the recovery procedure the same day you install: it is the part everyone postpones and the only one you ever use in a hurry. The Spanish version of this article is at Pocket ID vs Authelia vs Authentik: qué SSO elegir.

Sources

1. installation documentation
2. Pocket ID, proxy services guide
3. Pocket ID, account recovery
4. authelia/authelia, project repository and README
5. Authelia, OpenID Connect 1.0 integration guide
6. Authelia, roadmap
7. Authentik, available providers
8. Authentik, outposts
9. Authentik, installation with Docker Compose