Authentik’s current release line is 2026.8, and the project has quietly become the default answer in self-hosted communities to a question that used to have only one serious answer: Keycloak. The reason is architectural as much as it is practical. Since the 2025.10 release, Authentik dropped its Redis dependency entirely, folding caching, background tasks, and WebSocket handling into PostgreSQL, which cuts a self-hosted identity stack down to three containers instead of four. For teams tired of paying per-seat fees to Okta or Auth0, or tired of wrestling with Keycloak’s Java-heavy realm model, that simplicity matters. This tutorial walks through a complete Authentik deployment, from a blank Linux host to a working single sign-on (SSO) setup protecting a real application, using the current 2026.8 release.
By the end, you will have Authentik running behind a reverse proxy with TLS, a working OIDC application connection, a proxy outpost protecting an app that speaks no authentication protocol at all, and multi-factor authentication enforced through WebAuthn and TOTP. Every command below targets the current stable release, and every version number, CPU figure, and CVE reference comes from Authentik’s own documentation and release notes rather than guesswork.
Don't miss new tech stories on Google
Add Tech Insider once in the Google app and our stories appear in your news suggestions.
What Is Authentik and Why It’s Gaining Ground on Keycloak
Authentik is an open-source identity provider (IdP) built by Authentik Security Inc. that centralizes authentication for every application behind a single login screen. Instead of each app storing and verifying its own passwords, apps redirect users to Authentik, which authenticates them and returns a signed token carrying roles, groups, and custom claims that downstream services trust without asking the user to log in again. That is the same pattern Okta and Auth0 sell as a subscription, except Authentik’s core, protocols, unlimited users, MFA, and policy engine included, ships free under an MIT-style open license. The free edition covers OIDC, SAML, LDAP, SCIM, RADIUS, Kerberos, and proxy protocols, along with OAuth 2.0 token exchange and key-bound ID tokens, and its 2026.8 release carries OpenID certification.
What sets Authentik apart from Keycloak, which we covered in detail in our Keycloak SSO setup guide, is the flow-based configuration model. Keycloak configures authentication through realm settings and authenticator bindings; Authentik treats every login, enrollment, or password-reset sequence as a visual flow built from interchangeable stages. That makes edge cases, like forcing a password reset only for users without MFA enabled, something you build with drag-and-drop logic rather than custom code. It also ships outposts, lightweight proxy agents that can protect applications with no built-in OIDC or SAML support at all, a feature that fills the gap Authelia occupies but with a far richer policy engine behind it.
Flows, Stages, and Outposts Explained
Three concepts drive almost every decision in an Authentik deployment. A flow is a named sequence a user walks through, such as “default-authentication-flow” or “default-enrollment-flow.” A stage is one step inside that sequence, identification, password entry, an authenticator challenge, a consent screen, or a user-write step during signup. Because stages are reusable building blocks, the same MFA stage can sit inside both the login flow and a sensitive-action re-authentication flow without being configured twice. An outpost is a small deployed agent, usually a Docker container, that enforces Authentik’s decisions at the network edge: a proxy outpost sits in front of an app and only forwards traffic once Authentik confirms the user is authenticated, which is exactly how you protect a legacy internal tool that was never built with login logic of its own.
Who Should (and Shouldn’t) Self-Host an Identity Provider
Self-hosting an IdP makes the most sense for teams that already run their own infrastructure, have a handful of internal and customer-facing apps to unify under one login, and want authentication data to stay inside their own network boundary for compliance reasons. It makes less sense for a two-person startup that needs SSO for a single SaaS product tomorrow morning; a managed vendor removes operational burden entirely, at the cost of recurring per-user pricing that climbs fast as the user base grows. Even managed Keycloak hosting is not free: Clever Cloud’s price is scheduled to rise from €37.25 per month to €47 per month on November 1, 2026, and the €47 price includes up to 100 active users per month before usage-based charges apply. Authentik sits in between: the protocol implementation and security hardening are handled by the project, but you own the server, the database backups, and the upgrade cadence.
Real-World Use Cases for a Self-Hosted Identity Provider
Identity sprawl is the quiet cost center behind most mid-sized infrastructure teams: a dozen internal tools, each with its own login screen, its own password reset flow, and its own abandoned account from someone who left the company eight months ago. Authentik’s actual value shows up once you count how many of those logins disappear into one place. A typical deployment ends up fronting a Grafana dashboard, an internal wiki, a self-hosted Git server, and a handful of admin panels for infrastructure tools that were never built with multi-user authentication in mind, all behind the same login and the same MFA enforcement policy.
The split between OIDC-native applications and forward-auth-protected legacy tools is where the use case gets concrete. Modern tools like Grafana, Nextcloud, and most SaaS-style self-hosted apps speak OIDC directly, so Step 10’s provider configuration is all they need. Older internal dashboards, homegrown admin panels, or appliance web UIs that were never designed with a login system beyond a shared static password are exactly what the proxy outpost from Step 11 was built for. Running both patterns through the same Authentik instance means a single MFA policy and a single audit log cover every application in the stack, rather than security policy varying app by app depending on what that app’s developer happened to build in.
Migrating From Keycloak or Okta to Authentik: What Changes
Teams migrating off Keycloak typically find the protocol layer translates cleanly, since both platforms implement the same OIDC and SAML specifications, but the mental model does not. Keycloak’s realms map loosely to Authentik’s brands, and Keycloak’s clients map to Authentik’s provider-plus-application pair, but there is no one-to-one import tool that moves a realm export directly into Authentik’s blueprint format. In practice, migration means re-registering each application’s OIDC client from scratch: pull the client ID, secret, and redirect URIs out of the existing Keycloak realm, then recreate the matching provider and application entries in Authentik following Step 10 above. For a handful of applications this takes an afternoon; for dozens, writing a one-off script against each platform’s API to automate the transfer is worth the investment.
Migrating off a managed vendor like Okta or Auth0 carries a different kind of friction: those platforms often hold the only copy of certain federation configurations, particularly SAML metadata for enterprise customers who federate in through their own identity provider. Export every SAML metadata document and every OIDC client secret before cutting over, since regenerating a customer’s SAML integration after the fact usually means a support ticket on their end, not just yours. Run both identity providers in parallel for a transition window, migrating applications one at a time rather than flipping every login screen over in a single maintenance cut, so a misconfigured redirect URI on one app does not take down login for everything simultaneously.
Prerequisites: What You Need Before Installing Authentik
Confirm every item below before opening a terminal. Mismatched Docker Compose versions and skipped domain configuration are the two most common reasons a first Authentik deployment fails partway through setup.
| Requirement | Minimum Version / Spec | Notes |
|---|---|---|
| Authentik | 2026.8 | Pin this exact tag for server, worker, and any outpost images |
| Container runtime | Docker Engine 20.10+ with Compose v2, or Podman 3.0+ | Compose v1 (the standalone docker-compose binary) is not supported |
| Database | PostgreSQL 14 through 18 | PostgreSQL 16 or 17 is a safe, well-tested choice for new installs |
| Cache / queue | Not required since the 2025.10 release | Redis was fully removed from the standard deployment; older guides that add a Redis container are outdated |
| CPU | 2 cores minimum | 4+ cores recommended once you add outposts and background policy checks |
| RAM | 2 GB minimum | 4 GB or more recommended for anything beyond a personal homelab |
| Disk | 10 GB free | PostgreSQL volume, logs, and media assets grow with user count |
| Domain + TLS certificate | Any valid certificate (Let’s Encrypt works fine) | OIDC issuer URLs must match the hostname clients actually reach |
You will also want a subdomain, something like auth.yourdomain.com, pointed at the host before you start, since Authentik embeds that hostname in every token it signs. If you already run HashiCorp Vault for secrets management, keep it handy: storing the Authentik secret key and database password there instead of in a plaintext .env file is a sensible production habit, though this guide covers the simpler file-based approach first.
Step 1: Provision the Host and Lock Down the Firewall
Start from a clean, fully patched Linux host. A 2 vCPU / 4 GB cloud instance is enough to evaluate Authentik or run it for a small team.
sudo apt update && sudo apt upgrade -y
sudo apt install -y curl ca-certificates gnupg ufw openssl
sudo hostnamectl set-hostname auth-01Open only what Authentik and your own admin access actually need. Leaving port 9000 (Authentik’s default HTTP port) reachable from the open internet before TLS is configured is one of the fastest ways a fresh deployment gets probed.
sudo ufw allow OpenSSH
sudo ufw allow 443/tcp
sudo ufw deny 9000/tcp
sudo ufw deny 9443/tcp
sudo ufw enableStep 2: Install Docker Engine and Compose v2
Authentik’s official documentation requires Compose v2, which ships as a Docker plugin rather than the older standalone binary. Installing Docker through the official convenience script gets you both in one pass.
curl -fsSL https://get.docker.com -o get-docker.sh
sudo sh get-docker.sh
sudo usermod -aG docker $USER
newgrp docker
docker compose versionYou should see output confirming Compose v2, something like Docker Compose version v2.29.x. If the command is not found, your distribution likely installed the old Python-based docker-compose instead of the plugin; remove it and reinstall through the official script above.
Step 3: Download the Authentik Compose Template
Create a dedicated directory and pull the official Compose file rather than hand-writing one. This keeps you aligned with whatever service topology the current release actually ships.
mkdir -p ~/authentik && cd ~/authentik
wget -O docker-compose.yml https://goauthentik.io/version/2026.8/docker-compose.yml
touch .envOpen the downloaded file and confirm it defines three services, a PostgreSQL database, a server process, and a worker process, with no Redis container. If you are copying an older tutorial’s Compose file instead of downloading the current one, skip Redis entirely, since current releases no longer read Redis-related environment variables.
Step 4: Generate Secrets and Configure the .env File
Authentik’s secret key signs every session cookie and token it issues, so generate it with a cryptographically secure random source rather than typing something memorable.
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_TAG=2026.8.3" >> .env
echo "AUTHENTIK_ERROR_REPORTING__ENABLED=false" >> .env
cat .envPinning AUTHENTIK_TAG to 2026.8.3 instead of latest is the single most important line in that file. Authentik moved to a 3-month release cycle beginning with version 2026.5 in May 2026, with patch releases landing in between, and an unplanned major-version jump during a routine docker compose pull is a common way self-hosted deployments break overnight. Set file permissions tightly once the secrets are written.
chmod 600 .envStep 5: Launch the Containers and Verify Health
Pull the pinned images and bring the stack up in the background.
docker compose pull
docker compose up -d
docker compose psExpect output similar to this once all three services report healthy:
NAME IMAGE STATUS
authentik-db-1 postgres:16-alpine Up 45 seconds (healthy)
authentik-server-1 ghcr.io/goauthentik/server:2026.8.3 Up 40 seconds (healthy)
authentik-worker-1 ghcr.io/goauthentik/server:2026.8.3 Up 40 seconds (healthy)Database initialization and the first worker run typically take one to three minutes on modest hardware. Tail the server log if the status stays at starting longer than that.
docker compose logs -f serverStep 6: Run the Setup Wizard and Create the akadmin Account
Point a browser at http://your-server-ip:9000/if/flow/initial-setup/. Authentik serves a one-time setup flow here that disappears once an administrator account exists, so bookmark it only temporarily. Set a strong password for the built-in akadmin superuser and an email address Authentik can use for system notifications. After submitting the form, you land on the admin interface login screen, confirming the core stack is live and reachable.
If the page returns a connection refused error instead of the setup form, the server container is still finishing its first migration pass; wait another minute and retry rather than restarting the stack, which just resets that timer.
Step 7: Tour the Admin Interface and Set Branding
Log in as akadmin and open the admin interface at /if/admin/. The left navigation separates Applications, Providers, Outposts, Flows & Stages, and Directory (users, groups, roles). Before building anything, open System > Brands and set your default domain and a branding title. Authentik uses this brand configuration to decide which flow serves a given hostname, which matters the moment you run more than one application domain through the same instance.
This is also the right moment to review Directory > Tokens and generate an API token scoped to automation use if you plan to manage Authentik declaratively later through blueprints, which we cover in the advanced tips section below.
Step 8: Connect a Source or Keep the Built-In Directory
Authentik can authenticate users entirely from its own internal directory, which is the simplest starting point, or federate against an external source under Directory > Federation & Social login. Common sources include an LDAP-backed Active Directory, a SAML identity broker, or social login providers like Google and GitHub through OAuth2. For most new deployments, skip this step initially and rely on the built-in directory while you validate the rest of the flow; adding a source later is a configuration change, not a redeployment.
If you do connect an external source immediately, double-check the source’s “User matching mode” setting. Two 2026 advisories affecting Authentik versions before 2025.12.6, 2026.2.4, and 2026.5.1 both involved source-stage handling, one allowed a Source stage to be bypassed with an empty POST request, the other allowed an attacker controlling a linked source account to log in as an arbitrary existing account. Both are fixed in 2026.8.3, but they are a useful reminder to review source-linking permissions carefully rather than accepting defaults blindly.
Step 9: Build Your First Authentication Flow
Authentik ships a working default-authentication-flow out of the box, but understanding how to assemble one yourself is what makes the platform worth the learning curve. Navigate to Flows & Stages > Flows and inspect the default flow’s bound stages in order: identification, password, and (if configured) an MFA challenge. To build a custom variant, say, one that only prompts for MFA when a user signs in from a new device, create a new flow, then bind stages to it in sequence, each with its own policy conditions controlling whether that stage actually executes for a given login attempt.
Policies are the piece that makes flows genuinely flexible. A policy can check group membership, geographic IP range, or a custom expression written in Python, and that policy then gates whether a specific stage binding applies. This is the mechanism behind conditional access rules that would require a hardcoded configuration in simpler tools like Authelia.
Step 10: Create a Provider and Register an OIDC Application
Go to Applications > Providers and create a new OAuth2/OIDC provider. Set the authorization flow to your authentication flow from Step 9, choose a signing key, and set the redirect URI to match the callback URL your application expects, typically something like https://app.yourdomain.com/auth/callback. Save the provider, then open Applications > Applications and create an application entry that links to it, giving it a name, slug, and icon.
Once saved, Authentik exposes a discovery document at https://auth.yourdomain.com/application/o/your-app-slug/.well-known/openid-configuration. Any OIDC-compliant application, from a custom Node.js backend to an off-the-shelf tool like Grafana, reads that document to find the authorization, token, and user-info endpoints automatically. Verify it resolves correctly before wiring up the client application itself.
curl -s https://auth.yourdomain.com/application/o/your-app-slug/.well-known/openid-configuration | python3 -m json.toolStep 11: Deploy a Proxy Outpost for Forward-Auth Apps
Not every internal tool speaks OIDC or SAML. For those, Authentik’s proxy outpost sits between your reverse proxy and the app, checking authentication before forwarding traffic. In the admin interface, create a new proxy provider under Applications > Providers, choosing “Forward auth (single application)” mode, then create an outpost under Applications > Outposts and assign that provider to it. Authentik generates a deployable Compose snippet directly from the outpost’s detail page.
services:
authentik-proxy:
image: ghcr.io/goauthentik/proxy:2026.8.3
environment:
AUTHENTIK_HOST: https://auth.yourdomain.com
AUTHENTIK_TOKEN: <outpost-token-from-admin-ui>
ports:
- "9000:9000"
- "9443:9443"Once that outpost container is running, point your reverse proxy’s forward-auth directive at it instead of at the protected app directly. Anyone hitting the app without a valid Authentik session gets redirected to login first; everyone else passes straight through.
Step 12: Enable Multi-Factor Authentication
Under Flows & Stages > Stages, add an Authenticator Validation stage to your authentication flow, and an Authenticator Setup stage (WebAuthn or TOTP, or both) to your enrollment flow so new users are prompted to configure MFA the first time they sign in. WebAuthn, which covers hardware security keys and platform authenticators like Windows Hello or Touch ID, is the stronger option since it is phishing-resistant by design; TOTP remains useful as a fallback for users without a compatible device.
Pay close attention here if you enable email-based MFA. CVE-2026-94606, published September 24, 2026 and rated high severity, describes an MFA bypass through state confusion and parameter injection in the AuthenticatorEmailStage. A fix is available, which is one more reason to run the latest patch release of the 2026.8 branch (rather than any earlier release) and why WebAuthn or TOTP are safer primary MFA methods than email codes for anything protecting sensitive data.
Step 13: Put Authentik Behind a Reverse Proxy With TLS
Never expose Authentik’s raw HTTP port to the internet. Terminate TLS at a reverse proxy and forward only encrypted traffic. Here is a minimal Traefik label configuration added to the server service in your Compose file:
labels:
- "traefik.enable=true"
- "traefik.http.routers.authentik.rule=Host(`auth.yourdomain.com`)"
- "traefik.http.routers.authentik.entrypoints=websecure"
- "traefik.http.routers.authentik.tls.certresolver=letsencrypt"
- "traefik.http.services.authentik.loadbalancer.server.port=9000"If you prefer Nginx, a comparable server block forwards the same port behind a certificate issued by certbot. Either way, confirm the issuer URL Authentik reports in its OIDC discovery document matches the public HTTPS hostname exactly; a mismatch here is the most common reason token validation fails for client applications even though login itself appears to work. Pairing Authentik with a zero-trust overlay like Tailscale for the admin interface specifically adds a second layer that keeps the superuser login off the public internet entirely.
Authentik vs Keycloak vs Authelia: Which Identity Provider Fits
All three are free and open source, but they solve the same problem with different amounts of operational complexity. Keycloak, built originally by Red Hat, remains the heaviest and most enterprise-oriented of the three, with the broadest federation and brokering feature set. Authelia stays deliberately narrow, a lightweight authentication gateway built to sit in front of a reverse proxy, with far less configuration surface than Authentik or Keycloak. Authentik sits between them: a full identity provider with OIDC, SAML, LDAP-adjacent, and RADIUS-related support, plus the proxy-outpost pattern that gives it Authelia’s core strength without Authelia’s narrower protocol coverage.
| Factor | Authentik 2026.8 | Keycloak 26.8.x | Authelia |
|---|---|---|---|
| License | Open core (Enterprise tier adds features and support) | Apache 2.0 | Apache 2.0 |
| Deployment footprint | 3 containers (Postgres, server, worker); no Redis since 2025.10 | Typically Postgres + single Keycloak container | Single lightweight binary/container |
| Config model | Visual flows built from reusable stages | Realm settings and authenticator bindings | Static YAML configuration file |
| Protocol breadth | OIDC/OAuth2, SAML, LDAP/RADIUS-adjacent, SCIM, proxy outposts | OIDC/OAuth2, SAML, LDAP, Kerberos brokering | Forward-auth only; no OIDC provider role |
| Best fit | Mixed app environments needing both OIDC apps and legacy forward-auth apps | Large or enterprise environments needing deep federation | Small homelab or single-reverse-proxy setups |
| Learning curve | Moderate (flows and stages take time to internalize) | Steep (realm/client/role model is dense) | Low |
If your environment is a mix, some apps that speak OIDC natively and some legacy internal tools that speak nothing at all, Authentik’s outpost model usually wins on operational simplicity alone, since you are not running two separate identity systems to cover both cases.
5 Common Pitfalls When Deploying Authentik
Most Authentik deployment problems trace back to one of a handful of repeat offenders, and nearly all of them show up in the first week rather than months later. Reviewing this list before you go live catches the majority of support-forum questions the project’s community sees from first-time deployments.
Running an unpinned “latest” tag in production. Authentik ships releases frequently, and pulling latest on a routine docker compose pull can jump several minor versions at once, sometimes changing default behavior in flows you have not reviewed. Pin an explicit version like 2026.8.3 and upgrade deliberately after reading the release notes.
Mismatched server and worker image tags. The server and worker containers must run the exact same Authentik version. Updating one without the other is a frequent copy-paste mistake when editing Compose files by hand, and it produces confusing errors that look unrelated to versioning.
Forgetting the issuer URL has to match the public hostname exactly. If Authentik is reachable internally at one address and publicly at another, OIDC token validation breaks for any client application that fetches the discovery document from the public URL but receives tokens issued against a different internal hostname.
Copying an old Compose file that still includes Redis. Since the 2025.10 release, Authentik no longer reads Redis-related environment variables for its standard deployment. Adding a Redis container from an outdated tutorial wastes resources and can mask the fact that caching now lives entirely in PostgreSQL.
Treating the initial-setup flow URL as permanent. The /if/flow/initial-setup/ path is meant to be used once, immediately after first boot, to create the akadmin account. Leaving it bookmarked and assuming it stays available indefinitely leads to confusion later when the flow no longer appears because an admin account already exists.
Troubleshooting Authentik: 8 Issues and How to Fix Them
When something breaks, Authentik’s own logs are almost always faster to consult than a forum search, since the server and worker containers log stage failures, policy evaluation errors, and database connection issues directly to stdout. Run docker compose logs --tail=100 server worker as your first troubleshooting step before touching configuration, then cross-reference the symptom against the table below.
| Symptom | Likely cause | Fix |
|---|---|---|
| Server container stuck at “starting” for 5+ minutes | Database migration still running, or Postgres version below 14 | Check docker compose logs db for migration errors; confirm Postgres is 14 or newer |
| “Invalid redirect URI” on login | The provider’s configured redirect URI does not exactly match the client app’s callback URL | Edit the OAuth2/OIDC provider and match the URI character-for-character, including trailing slashes |
| Token validation fails even though login succeeds | Issuer URL mismatch between internal and public hostnames | Set the brand domain to the public hostname and confirm the discovery document uses it |
| Outpost shows “unhealthy” in the admin UI | Outpost token expired or outpost image version differs from the server version | Regenerate the outpost token and redeploy with a matching image tag |
| MFA enrollment stage never appears | Authenticator Setup stage not bound to the enrollment flow | Add the stage binding under Flows & Stages and confirm its order relative to other stages |
akadmin setup flow returns a 404 | An administrator account already exists | Expected behavior; log in normally or use the “forgot password” flow instead |
| Containers restart in a loop after an upgrade | Server and worker running mismatched versions, or a breaking change in the release notes was skipped | Set both images to the identical pinned tag and read the specific version’s release notes before retrying |
| LDAP or RADIUS outpost cannot reach the directory | Network policy or firewall blocking the outpost container from the upstream source | Confirm the outpost container can resolve and reach the source host on its configured port |
Advanced Tips: Blueprints, SCIM Provisioning, and GitOps Deployments
Once the manual setup above feels comfortable, move configuration into blueprints, Authentik’s declarative YAML format for defining flows, providers, applications, groups, and policies as code. A blueprint committed to version control turns a disaster-recovery rebuild from a multi-hour manual rebuild into a single docker compose up followed by a blueprint import.
version: 1
metadata:
name: demo-app-oidc
entries:
- model: authentik_providers_oauth2.oauth2provider
identifiers:
name: demo-app-provider
attrs:
client_type: confidential
redirect_uris: "https://app.yourdomain.com/auth/callback"
- model: authentik_core.application
identifiers:
slug: demo-app
attrs:
name: Demo App
provider: !KeyOf demo-app-providerFor organizations provisioning and deprovisioning accounts across many downstream SaaS tools, Authentik’s SCIM provider syncs user and group lifecycle events outward automatically, so disabling a user in Authentik propagates to connected apps instead of requiring a separate offboarding checklist. Combine that with a scheduled blueprint re-apply in CI, and your identity configuration becomes testable and reviewable the same way application code is, rather than a pile of undocumented clicks in an admin UI that only one person remembers how to reproduce.
Hardening Your Authentik Deployment for Production
Treat the akadmin account as a break-glass credential rather than a daily-use login. Create a named administrator account for routine work and reserve akadmin for recovery scenarios, logging and alerting on any login to it. Restrict network access to the admin interface specifically, ideally behind the same zero-trust overlay you might already use for other internal tools, and rotate the Authentik secret key and database password on a defined schedule rather than leaving the values generated during initial setup in place indefinitely.
Back up the PostgreSQL volume before every upgrade, not just periodically. Because Authentik now stores caching and background task state in Postgres rather than an ephemeral Redis instance, that single database is the entire source of truth for the deployment, which raises the cost of losing it and lowers the cost of a disciplined backup habit. Finally, subscribe to Authentik’s GitHub release notifications for the goauthentik/authentik repository so CVE fixes like the one addressing CVE-2026-94606 reach you the same week they ship rather than months later during an unrelated audit. If your organization already compares identity platforms at the vendor level, our breakdown of Microsoft Entra ID, Okta, and Auth0 is a useful companion read for weighing self-hosted versus managed options.
Logging and alerting deserve equal attention alongside backups. Authentik’s admin interface records every login attempt, policy denial, and administrative change under Events, but that log is only useful if something is actually watching it. Forward those events to whatever log aggregation system already monitors the rest of your infrastructure, and set an explicit alert on repeated failed logins against the akadmin account specifically, since that account is the single point of failure an attacker would target first. Rate-limit the authentication flow’s identification stage as well; Authentik’s flow policies can throttle repeated attempts from the same source, which blunts credential-stuffing attempts before they reach the password-verification stage at all.
Capacity planning matters more once outposts enter the picture. Each proxy outpost adds a network hop and a policy evaluation for every request to its protected app, so a high-traffic internal tool behind an outpost benefits from running the worker process with more allocated CPU than the 2-core minimum, since policy evaluation and token issuance both run through it. Monitor worker container CPU and memory under real traffic for a week before assuming the minimum spec from the prerequisites table is sufficient for your actual usage pattern, not just the setup and testing phase.
Complete Working Project: Authentik, Traefik, and a Protected Demo App
Putting every step above together, here is the full topology for a small production-realistic deployment: Traefik terminates TLS and routes two hostnames, Authentik handles identity, and a proxy outpost protects a demo internal app that has no login logic of its own.
services:
traefik:
image: traefik:v3.1
command:
- "--providers.docker=true"
- "--entrypoints.websecure.address=:443"
- "--certificatesresolvers.letsencrypt.acme.tlschallenge=true"
- "--certificatesresolvers.letsencrypt.acme.email=admin@yourdomain.com"
- "--certificatesresolvers.letsencrypt.acme.storage=/letsencrypt/acme.json"
ports:
- "443:443"
volumes:
- "/var/run/docker.sock:/var/run/docker.sock:ro"
- "letsencrypt:/letsencrypt"
db:
image: postgres:16-alpine
environment:
POSTGRES_PASSWORD: ${PG_PASS}
POSTGRES_USER: authentik
POSTGRES_DB: authentik
volumes:
- database:/var/lib/postgresql/data
server:
image: ghcr.io/goauthentik/server:2026.8.3
command: server
environment:
AUTHENTIK_SECRET_KEY: ${AUTHENTIK_SECRET_KEY}
AUTHENTIK_POSTGRESQL__HOST: db
AUTHENTIK_POSTGRESQL__PASSWORD: ${PG_PASS}
labels:
- "traefik.enable=true"
- "traefik.http.routers.authentik.rule=Host(`auth.yourdomain.com`)"
- "traefik.http.routers.authentik.entrypoints=websecure"
- "traefik.http.routers.authentik.tls.certresolver=letsencrypt"
- "traefik.http.services.authentik.loadbalancer.server.port=9000"
worker:
image: ghcr.io/goauthentik/server:2026.8.3
command: worker
environment:
AUTHENTIK_SECRET_KEY: ${AUTHENTIK_SECRET_KEY}
AUTHENTIK_POSTGRESQL__HOST: db
AUTHENTIK_POSTGRESQL__PASSWORD: ${PG_PASS}
demo-app-proxy:
image: ghcr.io/goauthentik/proxy:2026.8.3
environment:
AUTHENTIK_HOST: https://auth.yourdomain.com
AUTHENTIK_TOKEN: ${OUTPOST_TOKEN}
labels:
- "traefik.enable=true"
- "traefik.http.routers.demoapp.rule=Host(`app.yourdomain.com`)"
- "traefik.http.routers.demoapp.entrypoints=websecure"
- "traefik.http.routers.demoapp.tls.certresolver=letsencrypt"
- "traefik.http.services.demoapp.loadbalancer.server.port=9000"
volumes:
database:
letsencrypt:Bring the whole stack up, complete the setup wizard, create the OIDC provider for any app that supports it, and configure the proxy outpost for app.yourdomain.com exactly as described in Step 11. The result is a single login screen in front of both a modern OIDC-aware application and a legacy tool that was never built with authentication of its own, which is the practical payoff of running Authentik instead of a narrower single-purpose tool. Teams that also need passwordless options for that login screen should look at our FIDO2 passkey admin setup guide for pairing passkeys with the WebAuthn stage described in Step 12.
Frequently Asked Questions
Is Authentik completely free to use?
The core platform, including OIDC, SAML, proxy outposts, flows, and MFA, is free and open source with no user limit. Authentik Security also sells a paid Enterprise tier, listed at $5 per user per month and $0.02 per external user per month, billed annually. It adds Google Workspace and Microsoft Entra ID integrations, enhanced audit logging, and preview features such as privileged access management and Windows and Linux device login, with ticket-based support on subscriptions over $1,000 a year. An Enterprise Plus plan, starting at $20,000 a year, adds dedicated support, SLAs, and FIPS-compliant deployments.
Do I still need Redis to run Authentik?
No. Starting with the 2025.10 release, Authentik migrated caching, background tasks, the embedded outpost, and WebSockets to PostgreSQL, removing the Redis requirement from the standard deployment entirely.
What is the current stable version of Authentik?
The current release line is 2026.8, as of this writing. Always check the official GitHub releases page for the latest patch release before deploying, since Authentik ships updates frequently.
Is Authentik better than Keycloak?
Neither is strictly better; they trade off differently. Authentik’s flow-based configuration and built-in proxy outposts tend to suit mixed environments with both modern and legacy apps, while Keycloak’s deeper federation and brokering feature set tends to suit large enterprises already standardized on it.
Can Authentik protect an app that doesn’t support OIDC or SAML?
Yes, through a proxy outpost running in forward-auth mode. The outpost intercepts requests to the protected app and only forwards them once Authentik confirms a valid session, which works regardless of whether the app itself understands any authentication protocol.
How do I recover if I lose access to the akadmin account?
If you still have server access, you can reset the password directly through Authentik’s management command inside the worker container, or restore from a recent PostgreSQL backup. This is why routine backups of the database volume matter more for Authentik than for stateless services.
Does Authentik support hardware security keys?
Yes, through WebAuthn, which covers USB and NFC security keys as well as platform authenticators like Windows Hello and Touch ID. WebAuthn is the recommended primary MFA method since it resists phishing in ways that TOTP codes and email-based codes cannot.
What database versions does Authentik support?
PostgreSQL 14 through 18 are supported as of the 2026.8.x line. PostgreSQL 16 or 17 is a reasonable default for a new installation, balancing current features against broad ecosystem support.
