Centralized Auth for Your Homelab with Authelia

Every self-hosted app has its own idea of users. One has an admin user you cannot rename, another stores plaintext passwords, a third has no login at all and expects to be on a trusted network. Corralling all of that behind a single identity layer is one of the highest-value things a self-hoster can do. Authelia sits in front of your reverse proxy and answers one question per request: is this user authenticated and allowed this resource? Centralized auth means you set one strong password and one second factor, and retiring an app is as simple as removing its proxy rule instead of hunting down four different user databases.

How It Sits in the Request Path

Authelia is reverse-proxy middleware. Your proxy is configured so requests to protected apps first hit Authelia; if there is no valid session cookie, Authelia presents a login page, verifies the second factor, and issues a cookie that the proxy checks on subsequent requests. Your apps never see the login complexity — as far as they are concerned the traffic already came from an authenticated caller. Common setups pair Authelia with an LDAP backend or a simple YAML users file, and many use an OIDC-capable app to share the session onward.

A Two-Container Baseline

The smallest useful deployment is one container for Authelia plus your proxy, sharing a network. First create the users file, then a minimal configuration.

# users_database.yml
users:
  alice:
    displayname: "Alice"
    password: "$argon2id$v=19$m=65536,t=3,p=4$cm9vdHNhbHQ..."
    email: alice@example.com
    groups:
      - admins

The password must be a hashed value, which Authelia can generate for you. Pointing the config at this file and enabling two-factor brings up a working login in minutes. Note the file is mounted read-only so the config can never be mutated by the running service.

Wiring the Proxy With Caddy

With Caddy, protecting a subtree is a forward_auth block. Requests to the app are sent to Authelia first; a 2xx means pass through, anything else means redirect to login.

app.example.com {
    forward_auth 127.0.0.1:9091 {
        uri /api/authz/forward-auth
        copy_headers Remote-User Remote-Groups
    }
    reverse_proxy 127.0.0.1:3000
}

When Authelia approves, it stamps the resolved user and groups back into headers like Remote-User, which downstream apps can optionally honor. The result: one place to change the rules, one place to revoke access, and a consistent 2FA experience across every fronted service.

Enforcing by Group

You can make protection conditional. Public landing pages stay open while the admin area requires membership in the admins group — all expressed in Authelia's access control rather than scattered across apps.

OIDC for Apps That Speak It

Authelia is also an OpenID Connect identity provider, which means apps that natively support OIDC can trust it directly instead of going through the proxy. A service with a real login system — a wiki, a CI runner, a file-management front end — can be configured with Authelia as its single source of identity. The user logs in once at Authelia, and the app accepts that session via the standard OIDC flow. You keep the central account database and 2FA while the app keeps its own authorization roles.

Most self-hosted apps with OIDC support let you supply a client id, a client secret, an authorization endpoint, and a token endpoint. Authelia exposes these at well-documented URLs, and the configuration on the app side usually fits in a settings page rather than code. The benefit compounds: one password change, one 2FA enrollment, and one revocation point still apply even to apps that would otherwise insist on their own user table.

When Not to Front With Authelia

Two cases are worth keeping outside central auth. If an app is only reachable from a trusted local network and already has strong per-app credentials, adding a proxy auth layer is optional ceremony. And an app that needs service-to-service access without a human session — a bot fetching an API on a timer — should get an app-specific token rather than your personal account. Central auth handles humans; machines need their own scoped secrets.

Takeaway

Centralized auth turns a pile of inconsistent logins into one door with one lock. Add a second factor, let your proxy ask Authelia for every protected request, and your policy lives in one file instead of a dozen apps. You can run Authelia beside your proxy on a Netbay VPS and reach a consistent, 2FA-secured homelab in an afternoon — spin the host up at netbayhosts.in.