Tested with Authentik 2026.8.1 · Docker Compose · verified

Updated: 2026-09-02

Installing Authentik with Docker Compose deploys an IdP (identity provider: verifies who you are and what you’re allowed to access) that centralizes single sign-on, SSO: one login for every connected application. It uses OAuth2, OIDC, SAML, and LDAP, the standard authentication and directory protocols most business applications already speak. The current minimum stack is three containers: PostgreSQL, server, and worker, with no mandatory Redis since version 2025.10. An afternoon is enough to get web login and forward auth (delegated authentication: a reverse proxy like Traefik checks with Authentik before letting each request through) working on a couple of services.

This guide is also available in Spanish: Cómo instalar Authentik para SSO auto-alojado.

Key takeaways

  • Since version 2025.10, Authentik drops the Redis dependency entirely: the minimum stack is PostgreSQL + server + worker (three containers instead of four).
  • Forward auth with Traefik is the most common use case: protecting internal web services without modifying each application.
  • Three classic first-install problems: domain/URL configuration, cookie handling across subdomains, and persistent volumes for PostgreSQL.
  • Fits small and medium organizations well; for thousands of users or complex policies, Keycloak remains more powerful.
  • Never skip major.minor versions in upgrades: go one by one.

What has changed since 2025.10

This guide was written on the 2025.10 branch, the first without Redis. The current branch is 2026.8: 2026.8.0 shipped on 18 August 2026 and 2026.8.1, on 1 September 2026, is the tag the official compose.yml pins today. Checked on 2 September 2026 against the 2026.8 release notes[1] and the repository releases[2]. Nothing above about the Redis-free architecture changes; what follows is additive:

  • A change that breaks forward auth if you do not prepare for it: since 2026.8 the server only honours the X-Forwarded-Proto, X-Forwarded-Host and X-Forwarded-For headers when the connection comes from a trusted proxy network. Every address or network from which Traefik or Nginx connects directly to Authentik must be listed in AUTHENTIK_LISTEN__TRUSTED_PROXY_CIDRS; otherwise Authentik will see the request as plain HTTP and redirects will fail. Check it before upgrading, not after.
  • Two more breaking changes: the hash_password command no longer accepts the password as an argument (it prompts interactively), and the option to prevent duplicate WebAuthn devices is gone, with nothing to configure.
  • New in 2026.8: privileged access management (users request access to an application or an entitlement and an approver grants it with an expiry), switching from one signed-in account to another from the user interface, scheduled user offboarding (deactivation or deletion at a date and time), typed object attributes (text, number and Boolean with validation) on users, groups and entitlements, and event maps with a bundled basemap that makes no external requests, meant for air-gapped deployments. On OAuth 2.0 the project is now OpenID Certified and adds token exchange, on-behalf-of delegation, dynamic client registration and key-bound ID tokens. Agent accounts (service accounts acting on behalf of a user) are an Enterprise feature.
  • AUTHENTIK_POSTGRESQL__CONN_OPTIONS remains deprecated in 2026.8 and the notes still say it “will be removed in an upcoming version”. If you still have it, drop it.
  • Upgrading with Compose, as the notes describe it: wget -O docker-compose.yml https://goauthentik.io/version/2026.8/lifecycle/container/compose.yml then docker compose up -d. With this guide’s rule of not skipping versions, the path from 2025.10 goes through 2025.12, 2026.2 and 2026.5 before 2026.8. The official compose still uses PostgreSQL 16.

Why Authentik and not something else

The choice between Authentik, Keycloak, Zitadel, and commercial solutions like Auth0 depends on context, but for small-to-medium self-hosting the choice has clear nuances:

  • Keycloak[3]: powerful but heavy. Admin interface has a learning curve that slows teams without dedicated time.
  • Zitadel: elegant but younger and with a smaller ecosystem.
  • Auth0: excellent but stopped being a realistic option for anyone wanting to self-host.

Authentik occupies the middle ground: complete enough for real cases, with good SAML and OAuth2 support, with useful forward auth to protect services behind Traefik or Nginx, and with manageable resource consumption. A small instance runs comfortably with 2 GB of memory and a couple of cores. The official Authentik documentation[4] lists full sizing requirements per deployment size.

The architecture since 2025.10

An important change to understand before installing: in version 2025.10, Authentik removed Redis entirely, not made it optional. For years the minimum architecture was PostgreSQL + Redis + server + worker.

The process started in version 2024.6, replacing Redis locks with PostgreSQL advisory locks. It finished in 2025.10, when caching, the task queue, and WebSocket connections also moved to PostgreSQL, the latter using NOTIFY/LISTEN instead of Redis pub/sub. The Authentik team documents the change on their engineering blog[5].

This simplification has practical effects, with nuance:

  1. The stack drops from four containers to three, reducing configuration and failure surface.
  2. Anyone installing for the first time no longer has to explain why a Redis is hanging off the identity service.
  3. In exchange, Authentik now uses roughly 50% more PostgreSQL connections than before, since it absorbs the work Redis used to do. On instances with tight connection limits, check max_connections in PostgreSQL before upgrading.
  4. If PostgreSQL requires TLS, Authentik since 2025.10 requires TLS 1.3 or the Extended Master Secret extension to connect.

The basic deployment

The docker-compose.yml starts from the official one published by Authentik but simplified. It defines:

  • A postgresql service with version 16.
  • A server service with the ghcr.io/goauthentik/server image and server command.
  • A worker service with the same image and worker command.

The server exposes ports 9000 and 9443, which Traefik or Nginx use for forward auth.

Minimum environment variables:

  • AUTHENTIK_SECRET_KEY: a long random string used to sign tokens.
  • AUTHENTIK_POSTGRESQL__HOST: pointing to the database service.
  • AUTHENTIK_POSTGRESQL__USER, AUTHENTIK_POSTGRESQL__NAME, AUTHENTIK_POSTGRESQL__PASSWORD.

In serious deployments, move the password and the secret out of direct definition into a secrets manager or a git-ignored .env file (see our guide on environment variables and secrets in Docker Compose).

The tag to pin today is ghcr.io/goauthentik/server:2026.8.1 (1 September 2026), the same one the official compose.yml for the 2026.8 branch uses; when this guide was written it was 2025.10. If Authentik sits behind Traefik or Nginx, also set AUTHENTIK_LISTEN__TRUSTED_PROXY_CIDRS to the network the proxy connects from: since 2026.8 the X-Forwarded-* headers are only honoured from trusted proxies (details in the section above).

A useful detail: set memory and CPU limits on the containers from the start. The server can spike during mass logins or LDAP syncs, and without a declared limit can affect other services on the same host.

First start and migrations

When the server boots for the first time, it automatically runs database migrations. This process can take minutes, not seconds. A typical friction point is booting server and worker at the same time. On first install and on major upgrades, the best approach is:

  1. Start only the postgresql service and wait for its healthcheck to pass.
  2. Start the server and watch the logs (docker compose logs -f server) until migrations finish (a final line like Migrations applied).
  3. Start the worker.

If server and worker try to apply migrations at the same time, PostgreSQL locks can appear that require killing sessions manually with SELECT pg_terminate_backend(pid). This pattern also applies on sequential upgrades between major versions. You cannot skip major.minor, you must go one by one (for example, from 2025.8 to 2025.10, not straight from 2025.4 to 2025.10).

After migrations, the admin interface sits on port 9000 under /if/flow/initial-setup/ the first time. There, the initial admin user is created. Use a real email and save the password in a manager.

Forward auth with Traefik

The most common use case when adopting Authentik is protecting internal web services behind a reverse proxy (the component that receives every HTTP request and routes it to the right container). The pattern is called forward auth: Traefik receives the request, forwards it to Authentik to verify a valid session, and if none exists sends the user to login. If you already run Traefik, our guide on installing Traefik with Docker Compose covers the reverse proxy from scratch.

The configuration on the Authentik side follows these steps:

  1. Create a proxy provider with forward auth single application or forward auth domain.
  2. Create an application linked to it.
  3. Create an outpost that exposes the forward auth endpoint.

On the Traefik side, a middleware of type forwardAuth[6] points to the outpost, and that middleware applies to any router that should be protected.

A pattern I use is having two predefined middleware chains:

  • chain-base: for public services without authentication.
  • chain-oauth: for protected services passing through Authentik.

This clean separation makes adding or removing protection from a service a matter of changing a label, not rebuilding configuration.

Typical friction points

Three problems almost everyone runs into the first time:

  1. Domain and URL configuration. Authentik needs to know from which domain it is accessed to correctly generate redirects. The AUTHENTIK_HOST variable and the brand configuration inside the interface must match the real domain. If you put authentik.example.com in Traefik but Authentik thinks it is at localhost, redirects bring the user back to localhost and login does not work.
  2. Cookie handling across subdomains. For an Authentik session to protect services on different subdomains, cookies need to be configured with the parent domain. The solution is configuring the proxy provider with cookie domain pointing to the root domain (for example .example.com, with the leading dot).
  3. Data storage. The PostgreSQL database is critical and must live on a persistent volume (see our guide on Docker volumes and bind mounts) with backups configured, for example with Restic. More than one team has lost entire Authentik configurations by having the volume on tmpfs or by deleting the volume when running compose down -v by mistake.

Frequently asked questions

Do I need to install Redis to use Authentik?

No, not since version 2025.10. Authentik migrated caching, the task queue, and WebSocket notifications to PostgreSQL, so the minimum stack is three containers: PostgreSQL, server, and worker. In versions before 2025.10, Redis was mandatory.

Is Authentik better than Keycloak?

It depends on scale. For small or medium teams, Authentik installs faster and stays maintainable thanks to a simpler interface. For large organizations with thousands of users, complex federation, or strict compliance requirements, Keycloak offers more policy depth and a more mature community.

Conclusion

Authentik offers the best ratio of install effort to capabilities obtained in the self-hosted identity space. An afternoon is enough to have a working instance with web login and forward auth on a couple of services. If you are evaluating self-hosted identity and do not have extreme scale or specific compliance requirements, Authentik is the first candidate to try.

Where to pause and think: whether your organization has external users, partners, or customers who will also authenticate. Availability and federated identity requirements change a lot when SSO stops being internal. The good news is that this review can be done with Authentik already running on internal tasks, without needing to pick the final tool from day one.

Sources: official Authentik documentation[4], Authentik repository on GitHub[7], Authentik’s engineering blog on removing Redis[5], Traefik documentation on the ForwardAuth middleware[6].

Sources

  1. 2026.8 release notes
  2. repository releases
  3. Keycloak
  4. official Authentik documentation
  5. their engineering blog
  6. middleware of type forwardAuth
  7. Authentik repository on GitHub

Route: Self-hosting with Docker: from zero to production