Authelia: an SSO and 2FA portal that sits behind your reverse proxy

The gap Authelia fills between your proxy and your apps

Most self-hosted applications ship their own login form, or none at all. The README describes Authelia as an authentication and authorization server that acts as a companion for reverse proxies by allowing, denying, or redirecting requests. That sentence is the whole design: Authelia does not sit in front of your apps as a proxy itself. Your existing nginx, Traefik, Caddy, Skipper, Envoy or HAProxy instance forwards the auth decision to Authelia and then obeys the answer.

The audience is therefore narrow and specific. It is the operator who already terminates TLS on a proxy and wants one login screen, one second factor policy and one set of access rules across a group of internal services. It is not aimed at a team building a customer-facing identity product, and the README never presents it that way. Access control rules can match subdomain, user, group membership, request URI, request method and network, and the policy per rule can be one-factor or two-factor. That granularity is the reason people pick it over a proxy's built-in basic auth.

How the request flow works, and where state lives

A request arrives at your proxy. The proxy consults Authelia through the ForwardAuth middleware in Traefik, the forward_auth directive in Caddy, or the equivalent integration for the other supported proxies. Authelia answers with the authorization decision, and the proxy either passes the request through or sends the browser to the portal for authentication.

The portal is where the second factor happens. The README lists security keys supporting FIDO2 WebAuthn (devices like a YubiKey), time-based one-time passwords in a compatible authenticator app, and mobile push notifications through Duo. Passwordless authentication via WebAuthn passkeys is also listed, as is password reset with identity verification through email confirmation, and access restriction after too many invalid authentication attempts.

State is the part that shapes deployment. The README states Authelia is highly available using a remote database and Redis as a highly available KV store. That means the single-container quick start and a production deployment are different animals. There is also a separate OpenID Connect 1.0 / OAuth 2.0 provider, and the go.mod file shows the project depends on its own authelia.com/provider/oauth2 module rather than pulling in a general-purpose library.

Installing Authelia and getting one protected host working

The README lists the installation channels directly: the AUR, APT, FreeBSD Ports, a static binary, a .deb package, Docker, or Kubernetes. There is no npm or pip package. For a first look, the project points at the docker compose bundles under examples/compose, which the README describes as a starting point for anyone wanting to see Authelia in action, with the caveat that they come with self-signed certificates and must be customized. The Local bundle is intended for testing without worrying about configuration, with domains defined in the local hosts file. The Lite bundle is for a server exposed to the internet, with domains and DNS set up accordingly and certificates generated through LetsEncrypt.

If you build your own compose file, the image expects a configuration file at a fixed path. The Dockerfile sets this environment variable:

ENV \
	PATH="/app:${PATH}" \
	PUID=0 \
	PGID=0 \
	X_AUTHELIA_CONFIG="/config/configuration.yml"

The same Dockerfile exposes port 9091 and runs a health check every 30 seconds with a 3 second timeout and a 1 minute start period:

EXPOSE 9091

ENTRYPOINT ["/app/entrypoint.sh"]
HEALTHCHECK --interval=30s --timeout=3s --start-period=1m CMD /app/healthcheck.sh

Port 9091 is the port to point your proxy's auth subrequest at, and the health check is what a container orchestrator will use to decide the instance is ready. The repository also carries a config.template.yml at the top level, which is the starting point for the configuration file rather than a working configuration.

The proxy side is where the real work is. Authelia is compatible with Traefik out of the box through the ForwardAuth middleware, and with Caddy through the forward_auth directive. The README does not spell out the middleware configuration in the repository text; it links to the Get Started Guide and the integration pages for each proxy. Read those before writing the middleware, because the header names and the auth endpoint path are proxy-specific. Once the middleware is in place, the expected result is that an unauthenticated browser request to a protected host returns a redirect to the portal rather than the application.

Where Authelia is the wrong tool

The clearest limitation is stated by the project itself. The OpenID Connect 1.0 / OAuth 2.0 provider is described as still effectively on the roadmap as a beta, even though Authelia is OpenID Certified to the Basic OP, Implicit OP, Hybrid OP, Form Post OP and Config OP profiles. Certification and production-readiness are not the same claim, and the README makes that distinction rather than hiding it. If your only reason for deploying Authelia is to be an OIDC identity provider for a fleet of third-party applications, you are betting on a component the project labels beta.

The second limitation is architectural. Authelia is a companion for a reverse proxy, so it assumes you have one and that it can do auth subrequests. If your applications are not behind a proxy that supports that pattern, or if they must authenticate users directly against an identity API, Authelia's main mechanism does not apply. The proxy support list is explicit: nginx, Traefik, Caddy, Skipper, Envoy and HAProxy. Something outside that list is not covered by the README.

The third is operational. High availability requires a remote database and Redis. A single-container deployment is simpler but concentrates the failure domain: if Authelia is down and your proxy is configured to deny on failure, every protected application becomes unreachable at once. That is a deliberate trade-off of centralizing authentication, not a defect, but it changes what your monitoring has to cover.

How Authelia differs from Keycloak and Authentik

The comparison people search for is Authelia against Keycloak and Authentik, and the difference is one of scope rather than features. Keycloak is a full identity and access management server: it is the system of record for users, it federates identity providers, and it exposes the standards endpoints as the primary product. Authelia is not the system of record. The README describes it as a companion for a reverse proxy, and its user and group data comes from a file or an external directory through the LDAP dependency visible in go.mod. You bring the directory; Authelia enforces the policy at the proxy.

Authentik sits closer to Keycloak in that it presents itself as a complete identity platform with its own user interface and flows. Authelia's portal is a login and second-factor surface, not an administration console for identity lifecycle. If your requirement is self-service user registration, tenant management or per-customer branding, neither the README nor the repository layout suggests Authelia covers it.

The practical consequence: if you already have a directory and a proxy, Authelia adds the smallest amount of new machinery. If you do not have a directory, you will need one, and that is a separate project with its own operational cost.

Maintenance, licensing and what an upgrade actually costs

The repository is not archived and the last push was on 2026-05-26, which is the same timestamp as the v4.39.20 release. The two preceding releases, v4.39.18 and v4.39.19, landed in April 2026. The project is on a v4 module path, and go.mod declares go 1.27.0 with a toolchain of go1.27.1, so building from source requires a recent Go toolchain. The dependency list is long and includes fasthttp, cel-go, the go-webauthn library, pgx, the MySQL driver and sqlite3, which means a source build pulls a substantial dependency graph.

Licensing is Apache-2.0, and the repository carries a LICENSES directory plus REUSE.toml, which indicates REUSE-compliant per-file licence metadata rather than a single blanket file. Apache-2.0 permits commercial use and modification and includes a patent grant. It also requires that you preserve copyright and licence notices and state significant changes. If you fork and redistribute Authelia, or embed it in a product, those obligations follow. This is a description of the licence text, not legal advice; get counsel to review your specific distribution model.

Upgrade cost is dominated by configuration rather than code. The container reads /config/configuration.yml, and the repository ships config.template.yml as the reference for its shape. A major version bump is the moment to diff your configuration against that template, because removed or renamed keys are the typical breakage in a config-driven server. You are not compiling anything if you use the published image or package.

Editorial conclusion

Adopt Authelia if you already run nginx, Traefik, Caddy, Skipper, Envoy or HAProxy in front of internal apps and want one login plus a second factor without rewriting those apps. Do not adopt it as a general identity platform for external customers, and do not expect it to manage your users for you. Before committing, verify three things: that your proxy supports ForwardAuth or forward_auth, that you can run a remote database and Redis if you need high availability, and that the OpenID Connect provider, which the roadmap still lists as beta despite the certification, covers the flows your clients need.

Frequently asked questions

Official sources

1. Official documentation
2. Official README
3. Project repository
4. Release notes