One Login to Rule Your Entire Home Lab
Managing separate usernames and passwords across a dozen self-hosted services is the kind of friction that quietly kills home lab projects. Authentik solves that by acting as a central identity provider – one login that works across Grafana, Nextcloud, Gitea, Portainer, and anything else that speaks OIDC or SAML. Setting it up takes an afternoon, and the payoff is a genuinely professional authentication layer running entirely on your own hardware.
What Authentik Actually Does
Authentik is an open-source identity provider written in Python and Go, designed to handle authentication and authorization for web applications. It supports OAuth2, OpenID Connect (OIDC), SAML 2.0, LDAP, and RADIUS out of the box. That breadth of protocol support is what makes it useful in a mixed home lab environment where some services are modern and some are legacy.
Unlike lighter-weight options such as Authelia, Authentik ships with a built-in user management UI, a flow designer for customizing login experiences, and support for multi-factor authentication including TOTP, WebAuthn hardware keys, and static backup codes. You can also configure outpost proxies, which let Authentik guard applications that have no native authentication support at all. That last feature alone makes it worth the heavier resource footprint compared to simpler alternatives.
The architecture has two main components: the Authentik server itself and a background worker process. Both run as separate containers, and the stack also requires PostgreSQL for persistent storage and Redis for caching and task queuing. The official Docker Compose setup bundles all four containers together, which keeps the initial configuration manageable. You will also need a reverse proxy – Nginx Proxy Manager, Caddy, or Traefik all work well – to terminate TLS and route traffic to Authentik.
Plan for at least 2 GB of RAM dedicated to the Authentik stack. The Python-based server is not especially lightweight at startup, and under load – say, during a flow with MFA and email verification – it draws more than you might expect. On a machine with 8 GB or more that is a non-issue, but on a low-power device like a Raspberry Pi 4 you will feel it. A small NUC or any x86 mini PC is a more comfortable host.
Installing and Configuring Authentik with Docker Compose
Start by pulling the official Docker Compose file directly from the Authentik documentation. The project maintains a versioned compose file you can download with curl. At time of writing the stable release is in the 2024.x series. Create a working directory, drop the compose file inside it, and generate the two required secret values before touching anything else: a secret key and a password for the PostgreSQL database. The Authentik docs recommend using openssl rand -base64 36 for each. Store them in a .env file in the same directory – the compose file reads from it automatically.
The .env file needs at minimum four variables: AUTHENTIK_SECRET_KEY, PG_PASS, AUTHENTIK_ERROR_REPORTING__ENABLED (set to false if you want no telemetry), and AUTHENTIK_EMAIL__* variables if you plan to send verification or recovery emails. Email configuration is optional at install time but you will want it eventually for password resets and enrollment flows. Set SMTP_HOST, SMTP_PORT, SMTP_USERNAME, and SMTP_PASSWORD to match your mail provider or a local mail relay like Maddy or Postfix.
Run docker compose pull followed by docker compose up -d. The first startup takes longer than subsequent ones because Authentik runs database migrations on boot. Give it two to three minutes, then check the logs with docker compose logs -f server. You are looking for a line confirming the server is listening on port 9000 (HTTP) and 9443 (HTTPS). The initial admin account is created by navigating to https://your-server-ip:9443/if/flow/initial-setup/ in a browser. Set a strong password here – this account has full control over every policy and application in your identity provider.
Once inside the admin interface, the first task is creating an application and a provider. The provider defines the protocol – for most modern self-hosted apps you will choose OAuth2/OIDC. Give it a name, set the authorization flow to the built-in default-provider-authorization-implicit-consent flow to start, and copy the generated client ID and client secret. Then create an application that references this provider. The application entry is what shows up in the Authentik user portal at /if/user/ and what maps the provider to a display name and icon. Most services need only the client ID, client secret, and the OIDC discovery URL, which Authentik exposes at https://your-authentik-domain/application/o/application-slug/.well-known/openid-configuration.
Configure your reverse proxy to point a clean subdomain – something like auth.yourdomain.com – at the Authentik server on port 9000 or 9443. Caddy makes this nearly automatic with automatic HTTPS, but Nginx Proxy Manager works just as well if you are already using it for other services. Update the AUTHENTIK_EMAIL__FROM and any redirect URI settings inside each provider to use the real domain rather than an IP address. Authentik enforces redirect URI matching strictly, so any mismatch between the URI configured in the provider and what the client application sends will result in a failed login. Double-check those URIs before testing.
Connecting Your First Application
Grafana is a good first integration because its OIDC setup is well-documented and forgiving. In grafana.ini or the equivalent environment variables, enable the generic OAuth section and fill in the client ID, client secret, auth URL, token URL, and API URL – all derivable from the OIDC discovery document Authentik provides. Set role_attribute_path to map Authentik group membership to Grafana roles if you want admin users to carry their permissions over automatically. Restart Grafana, click the new SSO login button, and you should land back in Grafana already authenticated.
From there, the process for other applications is largely the same: create a provider and application in Authentik, copy the credentials, paste them into the target service’s OAuth or OIDC configuration, and verify the redirect URI on both ends. Nextcloud, Gitea, Portainer, Jellyfin, and Immich all support OIDC with varying levels of setup complexity. Where applications lack native SSO, Authentik’s outpost proxy feature can sit in front of the app and handle authentication at the network layer before requests ever reach the application itself.
