Caption: Authentik can become the central sign-in layer for self-hosted applications, developer tools, and internal dashboards.
Introduction
Authentik is an open-source identity provider that helps you centralize login, multi-factor authentication, and application access across a self-hosted environment. Instead of creating separate local accounts in every dashboard, wiki, monitoring tool, and admin panel, you can send users through one controlled identity flow and then grant access through protocols such as OAuth2, OpenID Connect, SAML, LDAP, and forward authentication.
For a small homelab, Authentik reduces account sprawl. For a team, it gives administrators a place to enforce password policy, recovery flows, MFA, group membership, and application assignments. It is especially useful when your infrastructure includes a mix of modern applications that support OIDC, older tools that only support LDAP, and web services that need a reverse-proxy login screen in front of them.
This guide installs Authentik on Ubuntu 24.04 LTS using the official Docker Compose deployment. Nginx terminates HTTPS, Authentik listens on local ports, PostgreSQL and Redis run from the Compose stack, and email delivery is configured for recovery and notifications. By the end, you will have Authentik available at https://auth.example.com, an admin account, a backup routine, and a first OIDC provider that can protect another self-hosted application.
Why Choose Authentik?
- Single sign-on for many apps: Use one identity platform for applications that support OpenID Connect, OAuth2, SAML, LDAP, or proxy-based authentication.
- Flexible login flows: Authentik's flow system lets you customize enrollment, recovery, MFA, consent, and policy decisions without writing a separate authentication service.
- Self-hosted control: User accounts, groups, provider settings, and audit events remain on infrastructure you operate.
- Docker-friendly deployment: The official Compose setup includes the Authentik server, worker, PostgreSQL, and Redis services needed for a small deployment.
- Access policies and groups: Grant or deny application access based on group membership, expressions, and provider settings.
- Outposts for edge cases: Proxy, LDAP, and RADIUS outposts help bridge applications that cannot talk directly to modern SSO protocols.
- Active documentation: Authentik has official installation, configuration, troubleshooting, and upgrade documentation that is worth keeping close during operations.
Authentik is a good fit when you already operate several internal services and want a single control plane for authentication. It is less useful if you run only one or two applications, do not need shared accounts, or would rather outsource identity operations to a managed service.
Prerequisites
Hardware Recommendations:
- 2 CPU cores and 2 GB RAM for a small team or homelab deployment
- 4 GB RAM if the same VPS also runs reverse proxies, monitoring, or several application containers
- 20 GB free disk space to start, plus room for database growth, media uploads, logs, and backup archives
- SSD storage for PostgreSQL and Redis persistence
- A second server, NAS, or storage account for off-host backups
Software and Accounts:
- Ubuntu 24.04 LTS server with sudo access
- A domain such as
auth.example.com - DNS
AorAAAArecord pointing that hostname to the server - Docker Engine and the Docker Compose plugin
- Nginx and Certbot for HTTPS
- SMTP credentials for password recovery, enrollment, and alert emails
- A password manager for the PostgreSQL password, Authentik secret key, bootstrap password, and recovery codes
Security Notes:
- Treat Authentik as critical infrastructure. If it is down, protected applications may be unreachable.
- Expose only HTTPS to the public internet. Keep Authentik's container ports bound to localhost behind Nginx.
- Enable MFA for the admin account before onboarding other users.
- Keep at least one tested backup and one documented recovery path outside the Authentik host.
- Review the Docker socket mount in the official Compose file. Authentik uses it for outpost management, but it gives the worker container sensitive host-level access.
Start with an updated host and a simple firewall policy:
sudo apt update
sudo apt upgrade -y
sudo apt install -y ca-certificates curl gnupg git ufw nginx certbot python3-certbot-nginx wget openssl
sudo ufw allow OpenSSH
sudo ufw allow 80/tcp
sudo ufw allow 443/tcp
sudo ufw enable
sudo ufw status
Installation Guide
This deployment follows Authentik's official Docker Compose installation and places Nginx in front of the Authentik server. The Compose stack remains under /opt/authentik, and the public URL is https://auth.example.com.
1. Install Docker Engine
Install Docker and confirm the Compose plugin is available:
curl -fsSL https://get.docker.com | sudo sh
sudo usermod -aG docker "$USER"
newgrp docker
docker --version
docker compose version
If your shell does not pick up the new docker group immediately, log out and back in before continuing.
2. Create the Authentik Project Directory
Keep the Compose file, environment file, backups, and local notes together:
sudo mkdir -p /opt/authentik/backups
sudo chown -R "$USER":"$USER" /opt/authentik
chmod 700 /opt/authentik/backups
cd /opt/authentik
The containers manage their own named volumes through Docker Compose. The backups directory is a local staging area before archives are copied off the host.
3. Download the Official Compose File
Download the current Compose file from the Authentik documentation:
cd /opt/authentik
wget https://docs.goauthentik.io/compose.yml
The official file references the Authentik version current at the time you download it. During future upgrades, download the updated Compose file from the release notes or installation docs before pulling new images.
4. Generate Secrets and the Environment File
Generate the PostgreSQL password and Authentik secret key, then add basic production settings:
cd /opt/authentik
touch .env
chmod 600 .env
echo "PG_PASS=$(openssl rand -base64 36 | tr -d '\n')" >> .env
echo "AUTHENTIK_SECRET_KEY=$(openssl rand -base64 60 | tr -d '\n')" >> .env
echo "AUTHENTIK_ERROR_REPORTING__ENABLED=false" >> .env
echo "COMPOSE_PORT_HTTP=127.0.0.1:9000" >> .env
echo "COMPOSE_PORT_HTTPS=127.0.0.1:9443" >> .env
Binding the published ports to 127.0.0.1 keeps Authentik reachable only from the local reverse proxy. Store a copy of the generated values in your password manager before you depend on this server.
5. Add Email Configuration
Email is optional during the first boot, but it is important for recovery, enrollment, and alerting. Append your SMTP settings to .env:
read -rsp "SMTP password: " AUTHENTIK_SMTP_PASSWORD_VALUE
echo
cat >> .env <<EOF
AUTHENTIK_EMAIL__HOST=smtp.example.com
AUTHENTIK_EMAIL__PORT=587
AUTHENTIK_EMAIL__USERNAME=auth@example.com
AUTHENTIK_EMAIL__PASSWORD=${AUTHENTIK_SMTP_PASSWORD_VALUE}
AUTHENTIK_EMAIL__USE_TLS=true
AUTHENTIK_EMAIL__FROM=auth@example.com
EOF
nano .env
Replace the SMTP host, username, password, and sender address before starting the stack. If your provider uses implicit TLS on port 465, use AUTHENTIK_EMAIL__USE_SSL=true instead of AUTHENTIK_EMAIL__USE_TLS=true; do not enable both.
6. Start Authentik
Pull the images and start the stack:
cd /opt/authentik
docker compose pull
docker compose up -d
docker compose ps
docker compose logs --since=2m server worker
The server listens locally on port 9000 for HTTP and 9443 for HTTPS. PostgreSQL stores Authentik data, Redis supports caching and task coordination, and the worker handles background jobs.
Caption: Nginx exposes HTTPS publicly while the Authentik server, worker, PostgreSQL, and Redis services stay inside the Docker Compose deployment.
7. Configure Nginx and HTTPS
Create /etc/nginx/sites-available/auth.example.com:
server {
listen 80;
listen [::]:80;
server_name auth.example.com;
client_max_body_size 100M;
location / {
proxy_http_version 1.1;
proxy_set_header Host $host;
proxy_set_header X-Real-IP $remote_addr;
proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for;
proxy_set_header X-Forwarded-Proto $scheme;
proxy_set_header Upgrade $http_upgrade;
proxy_set_header Connection "upgrade";
proxy_pass http://127.0.0.1:9000;
}
}
Enable the site and request a certificate:
sudo ln -s /etc/nginx/sites-available/auth.example.com /etc/nginx/sites-enabled/
sudo nginx -t
sudo systemctl reload nginx
sudo certbot --nginx -d auth.example.com
After Certbot updates the virtual host, open https://auth.example.com. If you see a login page or setup flow, the proxy and TLS path are working.
8. Complete the Initial Setup
Visit the initial setup flow in a browser:
https://auth.example.com/if/flow/initial-setup/
Create the first administrator account, save recovery codes, and immediately enable MFA for that user. Then open the admin interface and review System > Tenants so the external URL matches https://auth.example.com.
Configuration
Verify Runtime Configuration
Authentik can show the effective configuration from inside the worker container:
cd /opt/authentik
docker compose run --rm worker ak dump_config
Use this after editing .env to confirm that email settings, PostgreSQL settings, and trusted proxy settings are loaded as expected. Apply environment changes with:
docker compose up -d
Trusted Proxy and Real Client IPs
The default trusted proxy CIDRs include localhost and common private networks. For this Nginx-on-same-host deployment, Nginx connects from 127.0.0.1, so Authentik should accept X-Forwarded-For and X-Forwarded-Proto correctly. If you move Nginx to another host or load balancer, set AUTHENTIK_LISTEN__TRUSTED_PROXY_CIDRS in .env to include only the proxy network that should be allowed to send those headers.
Docker Socket Review
The official Compose file may mount /var/run/docker.sock into the Authentik worker for automatic outpost deployment and management. This is convenient when you use proxy or LDAP outposts, but a Docker socket mount is powerful. If you do not plan to use automatic outpost management, review the Compose file and remove that mount, or place a Docker Socket Proxy in front of it as described by the Authentik documentation.
Backups
Back up Authentik before upgrades and after major configuration changes. The most important data lives in the PostgreSQL database, but a practical backup also includes .env, the Compose file, and named volumes:
cd /opt/authentik
mkdir -p backups
BACKUP_DATE="$(date +%F-%H%M%S)"
docker compose exec -T postgresql pg_dumpall -U authentik > "backups/authentik-postgres-${BACKUP_DATE}.sql"
cp compose.yml ".env" backups/
docker run --rm \
-v authentik_media:/media:ro \
-v "$PWD/backups:/backup" \
alpine tar czf "/backup/authentik-media-${BACKUP_DATE}.tar.gz" -C /media .
tar czf "backups/authentik-config-${BACKUP_DATE}.tar.gz" compose.yml .env
Copy the resulting files to another server or storage provider:
rsync -av --progress /opt/authentik/backups/ backup-user@backup.example.com:/srv/backups/authentik/
Test restores on a separate host before you rely on these archives. A backup that has never been restored is only a guess.
Usage
First Login Checklist
After the setup flow completes:
- Confirm the admin user can log in at
https://auth.example.com. - Enable MFA for the admin user.
- Create a second emergency admin account and store its recovery details securely.
- Confirm SMTP delivery by sending a test recovery or invitation email.
- Review the default tenant branding, domain, and flow assignments.
- Create groups such as
admins,developers, andread-only-users. - Add one non-admin test user before onboarding the rest of your team.
Create an OIDC Provider for an Application
Most modern self-hosted applications can use OpenID Connect. In Authentik, create an application first, then attach an OAuth2/OpenID provider to it.
Example values for a documentation site at https://docs.example.com:
- Application name:
Docs - Slug:
docs - Launch URL:
https://docs.example.com - Redirect URI:
https://docs.example.com/oauth/callback - Subject mode: based on the application's recommendation
- Signing key: Authentik's default signing key unless your policy requires a dedicated key
Copy the client ID, client secret, issuer URL, authorization URL, token URL, and userinfo URL into the target application. The issuer URL is usually:
https://auth.example.com/application/o/docs/
The exact redirect URI and claim mapping depend on the application you are integrating, so use that application's OIDC documentation for the final values.
Caption: A protected application redirects users to Authentik, Authentik evaluates policy and MFA, and successful users return with an OIDC token.
Protect a Legacy Web App
For applications that do not support OIDC or SAML, Authentik's proxy outpost can sit in front of the service and enforce a login flow. This pattern is useful for small internal dashboards, but it needs careful proxy configuration because headers become part of the trust boundary. Start with a low-risk app, confirm logout behavior, and document which headers the upstream app receives.
Troubleshooting
- The initial setup URL returns a 404: Wait for migrations to finish and check
docker compose logs --since=5m server worker. The first boot can take a few minutes while PostgreSQL and Authentik initialize. - Nginx shows a bad gateway error: Confirm
docker compose psshows the server container healthy, then check that Nginx proxies tohttp://127.0.0.1:9000. - Browser login fails with CSRF errors: Verify
Host,X-Forwarded-Proto, andX-Forwarded-Forheaders are passed by Nginx. If the proxy is not on localhost, configureAUTHENTIK_LISTEN__TRUSTED_PROXY_CIDRSfor the proxy's network. - Email is not delivered: Check
AUTHENTIK_EMAIL__HOST, port, TLS or SSL mode, username, password, and sender address. Some VPS providers block outbound SMTP; use a mail relay on an allowed port if needed. - OIDC redirect mismatch: The redirect URI in Authentik must exactly match the URI expected by the application, including scheme, hostname, path, and trailing slash.
- Users can log in but cannot access an app: Review application assignments, group membership, provider policy bindings, and the user's events in the Authentik admin interface.
- Admin group was removed accidentally: Use Authentik's official troubleshooting documentation for missing admin groups rather than editing the database by hand.
- Outpost deployment fails: If you removed the Docker socket mount, deploy outposts manually or configure a Docker Socket Proxy with the required permissions.
Scaling, Securing, and Next Steps
For a small team, the single-host Docker Compose deployment is a practical starting point. As Authentik becomes a dependency for more applications, add monitoring for container health, PostgreSQL disk usage, certificate expiry, login failures, and SMTP delivery. Keep your upgrade process conservative: read the Authentik release notes, download the new Compose file when instructed, back up the database and configuration, pull images, and verify login plus one application integration before considering the upgrade complete.
The most important security improvements are operational rather than cosmetic. Require MFA for administrators, avoid sharing admin accounts, use groups for application access, limit trusted proxy CIDRs, keep the Docker socket decision intentional, and test restores. Document an emergency path for what to do if Authentik is unavailable, because identity outages can lock you out of the very tools you need to fix the outage.
By following this guide, you now have a self-hosted identity provider that can centralize login for your applications, enforce stronger access policies, and give you a foundation for SSO across a growing server environment. Next, integrate one low-risk application with OIDC, invite a test user, verify backup restoration on a separate host, and then gradually move additional services behind Authentik.