Updated: 2026-07-17

Installing Authentik with Docker Compose deploys an IdP (identity provider, the service that verifies who you are and what you’re allowed to access) that centralizes single sign-on, SSO (one login that opens several applications without re-entering credentials), using 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.

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[1]: very 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[2] 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, and 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[3].

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).

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 several minutes. 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[4] 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 hits 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. Several teams have 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 usually installs and stays maintainable faster 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 very 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[2], Authentik repository on GitHub[5], Authentik’s engineering blog on removing Redis[3], Traefik documentation on the ForwardAuth middleware[4].

Sources

  1. Keycloak
  2. official Authentik documentation
  3. their engineering blog
  4. middleware of type forwardAuth
  5. Authentik repository on GitHub

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