Why Self-Hosted SSO Makes Sense
Single sign-on is the kind of feature most people associate with enterprise IT departments and corporate login portals. But running your own SSO provider at home – or across a small business stack – solves a very real problem: the more self-hosted services you add, the more login screens, separate passwords, and duplicate user accounts you accumulate. Authentik changes that by acting as a central identity provider that handles authentication once, then passes verified sessions to every connected app.
Authentik is open source, actively maintained, and built with modern authentication protocols in mind – OAuth2, OpenID Connect, SAML, and LDAP are all supported out of the box. It runs cleanly in Docker, includes a polished admin UI, and handles everything from basic login flows to multi-factor authentication and user provisioning. For anyone already running Nextcloud, Immich, Grafana, or similar self-hosted tools, Authentik can replace the scattered credential management with one clean system.
What You Need Before You Start
The setup assumes you have Docker and Docker Compose installed on your server. A domain name with DNS pointed at your server is strongly recommended – Authentik works on a local IP, but HTTPS is required for most OAuth flows to function correctly in production. A reverse proxy like Nginx Proxy Manager or Traefik handles TLS termination cleanly and sits in front of Authentik without much configuration overhead. You will also want at least 2GB of RAM available, since Authentik runs several containers including a PostgreSQL database, a Redis cache, a background worker, and the main server process.
If you are running other self-hosted apps that you want to connect to Authentik, have those services accessible and note their callback or redirect URLs before you begin. You will need those URLs when creating application definitions inside Authentik. It helps to sketch out which services you plan to protect and whether they support OAuth2/OIDC or need LDAP – the configuration path differs slightly depending on the protocol each app uses.
Deploying Authentik with Docker Compose
Start by pulling the official Authentik Docker Compose file. The Authentik project publishes a maintained compose file at their documentation site, and the recommended approach is to download it directly rather than writing one from scratch. Run the following in your terminal to grab the latest version:
curl -o docker-compose.yml https://goauthentik.io/docker-compose.yml
Before starting the stack, generate a secret key and a password for the database. Authentik’s documentation suggests using openssl rand -base64 36 for both values. Create a .env file in the same directory and populate it with PG_PASS (the database password), AUTHENTIK_SECRET_KEY, and optionally AUTHENTIK_EMAIL__* variables if you want email-based password resets to work. The email configuration is optional for getting started but worth adding before you hand the system to other users.
Once your .env file is ready, run docker compose pull followed by docker compose up -d. The stack will take a minute or two to initialize, mostly because PostgreSQL needs to set up the database schema on first boot. After the containers stabilize, Authentik is accessible at http://your-server-ip:9000/if/flow/initial-setup/ for the first-run wizard, where you set your admin username and password. If you are putting Authentik behind a reverse proxy, configure that proxy to forward to port 9000 (HTTP) or 9443 (HTTPS) and set the AUTHENTIK_HOST environment variable to your public domain before completing the wizard.
After logging into the admin interface at /if/admin/, spend a few minutes in the System settings to confirm your external URL is set correctly. Authentik uses this URL to build redirect links during OAuth flows, so a mismatch here causes silent failures that are frustrating to debug later. Also navigate to Flows and Stages to review the default authentication flow – the out-of-box configuration is reasonable, but you may want to add a TOTP stage for multi-factor authentication before connecting your first app.
Connecting Your First Application
Authentik separates the concepts of Providers and Applications. A Provider defines the protocol and settings – OAuth2, SAML, LDAP proxy, and so on. An Application is the front-facing object that users see and that ties a Provider to an access policy. You create them in sequence: Provider first, then Application linked to that Provider.
For an app that supports OpenID Connect – Nextcloud, for instance, or Immich – navigate to Applications > Providers > Create and select OAuth2/OpenID Provider. Give it a name, set the authorization flow to the default, and add the redirect URI from your target application. Authentik will generate a Client ID and Client Secret automatically. Copy those values into your app’s SSO configuration – most apps have an OIDC or OAuth2 section in their settings that asks for the client ID, client secret, and the issuer URL, which in Authentik follows the format https://your-authentik-domain/application/o/your-app-slug/.
After saving, create the Application object under Applications > Applications > Create, select the Provider you just built, and assign a launch URL if you want the app to appear in Authentik’s user-facing app portal. From there, users can log into Authentik once and click through to any connected service without re-authenticating. Access policies under each Application let you restrict which users or groups can reach that service, which is useful if you are running shared infrastructure where not everyone should have access to everything.
Hardening and Ongoing Management
Authentik logs authentication events, policy decisions, and outbound requests under Events > Logs. Reviewing these periodically is the fastest way to catch misconfigured redirect URIs or failed MFA attempts before they become a real problem. The event retention period is configurable – shorter retention reduces database size, which matters on low-storage VPS instances.
For user management at scale, Authentik supports SCIM and LDAP outpost deployments, which let directory-aware applications pull user data directly rather than relying on login-time token exchange. The LDAP outpost runs as a separate container and proxies LDAP queries to Authentik’s internal user store – useful for apps that predate OAuth2 and only speak LDAP. Configuring an outpost involves creating an Outpost object in the admin UI, selecting the LDAP provider, and pointing the outpost container at your Authentik instance using an API token you generate from the admin panel.
Backups deserve attention early rather than after something breaks. The critical data lives in the PostgreSQL container – a nightly pg_dump piped to a compressed file covers most failure scenarios. Authentik also exports configuration via System > Blueprints, which capture your flows, providers, and application definitions in a portable YAML format. Between a database dump and an exported blueprint, restoring to a fresh server after a failure is a matter of hours, not days. The one thing a blueprint does not capture is the secret key in your .env file – if you lose that, tokens issued before the key change become invalid and all connected sessions break immediately.
