authentik vs Authelia with Traefik forward auth

Both products use the same basic pattern: Traefik sends each incoming request to an auth service before the backend app sees it. If the request has no valid session, the user is redirected to a login portal, and once a session exists the request passes through to the app. The difference lies in where that auth service runs and what it has to be paired with. In authentik, the proxy outpost is embedded in the server container, so the same deployment that serves the admin UI and the login flows also answers forward-auth checks. In Authelia, the server is a separate companion service that the proxy asks on every request, so you run and route it as its own component alongside Traefik.

Authelia adds a hard constraint that changes how you plan the edge. Its session cookies require HTTPS, and the project declines to support plain HTTP, so every protected site and the Authelia portal must sit behind a valid TLS certificate before you test anything. Authentik's outpost integration does not carry that same stated requirement in the supplied documentation, but you should still serve it over HTTPS for session security. Plan certificate issuance and the public hostnames for the login portal first, because they affect every router you define.

The exact Traefik middleware configuration differs for each project, including how forwarded headers, the verification endpoint and the redirect behavior are declared. Do not copy a snippet from a blog or an older guide. Check the current authentik provider and proxy outpost documentation, and Authelia's Traefik integration guide, against the versions you plan to run, then test an unauthenticated request, a logged-in request and a logout in a non-production environment. Record which headers reach your backend, because apps that trust identity headers depend on that behavior.

The resource gap between these two options is structural: authentik runs as a server container with an embedded outpost, a worker container for background tasks and PostgreSQL, while Authelia is a single companion service that stores its data in PostgreSQL, MySQL or a local SQLite file. authentik's Docker Compose guide calls for a host with at least 2 CPU cores and 2 GB of RAM and positions Compose for test setups and small-scale production, so that is the floor to plan around, not a sizing result for your traffic. Before you commit, confirm which database engine you will operate, because authentik always needs PostgreSQL while Authelia can run on SQLite for a single-host lab.

The authentik 2025.10 release notes state that authentik no longer uses Redis at all, moving caching, tasks, sessions and WebSocket functions to PostgreSQL. That removes one container from the stack, but it shifts load onto the database, and the release notes warn of roughly 50% more PostgreSQL connections after upgrading. If you already run an authentik release from before 2025.10, check your PostgreSQL max_connections headroom and connection pooling before you upgrade, and confirm the current figures against the release notes for the version you plan to deploy. Teams that do not already operate PostgreSQL should treat it as a new backup, patch and monitoring responsibility.

Measure rather than estimate. In a test deployment behind your Traefik instance, record idle and peak memory for each authentik container and for Authelia, along with PostgreSQL connection counts during a normal login burst, a scheduled sync and a restart of the proxy. Run the same test with your real number of protected applications and users, because forward-auth checks happen on every request to a protected route. The output tells you whether a small host is enough and which database settings need tuning, and it gives your quote request a concrete basis for hosting and operating effort.

Moving between a forward auth companion and a full identity provider is never just a proxy change. Authelia sits in front of Traefik and answers each request through the forward-auth middleware, so its users, second factor registrations and session policy live in Authelia's own storage. authentik's proxy outpost also protects apps, but the identity records, flows, groups and enrolled authenticators live in authentik's PostgreSQL database. Every app that uses OpenID Connect also holds its own client ID, client secret and redirect URIs, which must be recreated against the new issuer. Passkeys and TOTP devices are usually bound to the relying party and domain they were enrolled under, so users may need to re-enroll their second factors. Confirm with each vendor how their current version handles credential export and whether a relying party change is needed.

Limit the cost by writing down three things on day one: the redirect URI pattern for every protected app, the stable user identifier your apps rely on (for example, the username or email claim that goes into an application's account table), and the user backend, whether a YAML file, LDAP directory such as FreeIPA or Active Directory, or a database-backed store. If user records come from LDAP, the directory stays the source of truth and switching providers mostly means reconfiguring the connection rather than migrating accounts. If users live only inside one identity provider, keep an export or a scripted provisioning path so accounts can be recreated. Also record which apps use forward auth only and which use OIDC, because forward-auth apps usually need only a Traefik middleware change while OIDC apps need client work.

Before committing, ask each vendor and test in your own environment: how user and device data can be exported or imported, whether the current Authelia and authentik releases support migration tooling, and what the upgrade path looks like between the versions you run. Run a pilot with one non-critical app and a test user, then time how long re-enrollment takes for a real user. Keep the documented redirect URIs, identifiers and backend choices in version control next to your Traefik configuration so a future switch becomes a planned change rather than a rebuild.