Why centralize authentication on your VPS
When you accumulate self-hosted tools (Grafana, Nextcloud, Gitea, an internal dashboard), each brings its own user base and its own password policy. It's a nightmare to maintain and a multiplied attack surface. Authentik solves this by acting as an identity provider (IdP): it supports OAuth2/OIDC, SAML, LDAP and above all forward auth, which lets you protect any application behind a reverse proxy, even those with no notion of login at all. Self-hosting on a VPS guarantees that your credentials never pass through a third-party service and that you remain in control of the user tree and the MFA policies.
What you gain with Authentik
- A single set of credentials for all your applications, with centralized logout.
- MFA (TOTP, WebAuthn/FIDO2 keys, backup codes) applied uniformly by policy.
- Forward auth to protect "login-less" apps, impossible with a classic IdP.
- Fully customizable flows (registration, recovery, captcha, access conditions).
- OAuth2/OIDC, SAML and LDAP connectors to plug in both modern and legacy apps.
- Immediate access provisioning and revocation when a collaborator leaves.
Requirements for this deployment
Authentik is more demanding than a simple service: the stack includes the server, a worker, PostgreSQL and Redis. Count on a VPS with at least 2 vCPU and 4 GB of RAM for comfortable operation, 2 GB being a strict minimum that can struggle under load. Docker and Docker Compose are required, as well as a dedicated domain name (auth.mydomain.com) with an A record. A reverse proxy (Traefik, Nginx Proxy Manager or Caddy) is indispensable to handle SSL and forward auth to your other applications.
Deploy Authentik with Docker Compose
Get the official compose file and generate the secrets
Download Authentik's reference docker-compose.yml. Generate the sensitive values in a .env file: PG_PASS and AUTHENTIK_SECRET_KEY via openssl rand -base64 60. Never reuse an example key.
Start the stack
Run docker compose up -d. Four containers come up: server, worker, postgresql and redis. Monitor the initialization with docker compose logs -f server until you see the server ready to listen.
Finalize the installation via /if/flow/initial-setup/
On first launch, go to https://auth.mydomain.com/if/flow/initial-setup/ to set the password for the akadmin account. This is your super-administrator: protect it immediately with MFA.
Configure the reverse proxy and SSL
Route auth.mydomain.com to port 9000 (HTTP) or 9443 (HTTPS) of the server container via your reverse proxy, with a Let's Encrypt certificate. Authentik absolutely must be served over HTTPS for session cookies and WebAuthn to work.
Create a provider and an application
In the admin, create a Provider (OIDC for a modern app, or Proxy for forward auth) then the associated Application. For OIDC, retrieve the client_id / client_secret and the .well-known/openid-configuration URL to paste into the client app.
Protect an app with forward auth
For an application without native login, create a Proxy Provider and declare an authentication middleware in your reverse proxy pointing to the /outpost.goauthentik.io/auth/ endpoint. Any unauthenticated request is then redirected to Authentik before reaching the app.
Enable an integrated Outpost and leverage "property mappings" to inject headers (X-authentik-username, X-authentik-groups) into your forward auth applications: many apps (Grafana, for example) can read these headers to do user auto-provisioning and role assignment. You thus get not only SSO, but also a fully automated group-to-role mapping, without manual configuration in each tool.
