After following this series, you’re likely logging into a genuinely long list of separate services individually — Gitea, Uptime Kuma, Grafana, FreshRSS, Vaultwarden — each with its own login page and, ideally, its own strong password. Authelia consolidates authentication across these services into a single, centrally-managed sign-on layer, sitting in front of your reverse proxy to protect multiple applications with one consistent, hardened login.

What Is Authelia?

Authelia is a free, open-source authentication and authorization server designed to work alongside a reverse proxy, adding a unified login portal, multi-factor authentication, and access control policies in front of applications that might not have robust authentication features of their own. Rather than replacing each application’s own login, Authelia can intercept requests at the proxy level, requiring authentication before traffic ever reaches the underlying service.

Why Centralize Authentication

• One strong login instead of many – a single, truly hardened authentication point (with proper 2FA) protecting multiple services, rather than relying on each individual application’s own authentication implementation and security track record
• Consistent 2FA across services that don’t natively support it – some self-hosted applications lack built-in two-factor authentication; Authelia adds this protection at the proxy layer regardless of the underlying application’s own capabilities
• Centralized access control – define which users can access which services from one place, rather than managing separate user accounts and permissions across a dozen different applications individually

How Authelia Works with Nginx Proxy Manager

Authelia integrates with reverse proxies (including Nginx, which underlies Nginx Proxy Manager, ) through an authentication subrequest mechanism — before allowing a request through to the protected backend service, the proxy first checks with Authelia whether the requester is properly authenticated, redirecting to Authelia’s login portal if not.

Installing Authelia with Docker

yaml

version: '3'
services:
  authelia:
    image: authelia/authelia:latest
    volumes:
      - ./authelia-config:/config
    environment:
      - TZ=America/New_York
    restart: unless-stopped

docker compose up -d

Basic Configuration Structure

Authelia’s configuration (configuration.yml within the mounted config directory) defines authentication backends, access control rules, and session behavior:

yaml

authentication_backend:
  file:
    path: /config/users_database.yml

access_control:
  default_policy: deny
  rules:
    - domain: "grafana.yourdomain.com"
      policy: two_factor
    - domain: "uptime.yourdomain.com"
      policy: one_factor

This example requires two-factor authentication specifically for accessing Grafana, while Uptime Kuma only requires standard password authentication — letting you apply stricter policies to your more sensitive services.

Setting Up Users

For a personal or small-scale homelab, Authelia’s file-based authentication backend is straightforward, defining users and hashed passwords directly in a YAML file, though it also supports LDAP integration for larger setups wanting centralized directory-based user management.

Connecting Nginx Proxy Manager to Authelia

Within Nginx Proxy Manager’s custom configuration for each protected proxy host, add the authentication subrequest configuration pointing at your Authelia instance, following Authelia’s official Nginx integration documentation for the specific configuration snippet required.

Enabling Two-Factor Authentication

Authelia supports TOTP-based 2FA , letting users register an authenticator app during their first login, after which the configured access control policy determines which protected services actually require that second factor.

A Practical Policy Structure

• Public or low-sensitivity services (a public status page, perhaps) – no authentication required, or default_policy bypass
• Standard internal services (FreshRSS, a personal dashboard) – one_factor (password only)
• Sensitive services (Vaultwarden’s admin panel, Grafana, Gitea) – two_factor requiring both password and TOTP code

Considering the Added Complexity

Authelia introduces a real additional layer between users and your services, meaning its own availability becomes a dependency for accessing everything behind it — worth weighing against the High Availability considerations if your homelab has grown complex enough that authentication downtime would really disrupt access to multiple critical services simultaneously.

Final Thoughts

Setting up Authelia for single sign-on brings actually centralized, consistently hardened authentication across the growing list of services built throughout this series, rather than depending on each individual application’s own authentication implementation and default security posture. For a homelab that’s accumulated as many separate services as this series covers, consolidating authentication through Authelia significantly reduces both the cognitive overhead of managing separate logins and the security inconsistency of relying on each application’s own, potentially weaker, built-in authentication.

Related Posts

• How to Use Nmap for Network Security Scanning
• How to Set Up Two-Factor Authentication for SSH on Linux
• How to Set Up a Firewall on Linux with UFW