What are we building?

We attach two services, each the appropriate way:

• Forward auth for an application without its own login. Traefik asks Authentik before every request whether the visitor is signed in. If not, they land on the Authentik login page; if they are, the application receives their identity as HTTP headers.
• OpenID Connect (OIDC) for applications with SSO support – Grafana, Nextcloud, Forgejo, Immich and many others. There you enter client ID, secret and the endpoints, and the app does the rest.

Everything below was carried out with Authentik 2026.8 behind Traefik v3.7 on Debian 13: at the end the test service shows the forwarded identity headers, and the OIDC discovery document returns real endpoints.

Which route for which service?

The decision is almost always clear-cut:

In short: OIDC where possible, forward auth where necessary. OIDC gives the application a real user account including roles; forward auth only puts a door in front of it and passes a name through in a header.

Prerequisites

• A running Authentik from part 1, reachable at https://YOUR_DOMAIN
• A Traefik v3 with a proxy network (guide) – we work a lot with middlewares here, the basics are in hardening Traefik
• A service to practise on. We use traefik/whoami because it echoes every header it receives – which makes it immediately obvious whether the integration really works

Step by step

1. Access for automation: an API token

Providers and applications can be created entirely through the API – handy, because it makes your work reproducible instead of click-based. For that, Authentik needs a token.

Because you went through the setup wizard in part 1, akadmin already exists. So you create the token in the interface: Directory → Tokens and App passwords → Create token. Use a descriptive identifier (api-setup), set the intent to API and the user to akadmin. After saving, copy the key via the copy icon – it is shown only once.

docker compose run --rm server hash_password

  worker:
    environment:
      AUTHENTIK_BOOTSTRAP_PASSWORD_HASH: ${AK_BOOTSTRAP_PASSWORD_HASH}
      AUTHENTIK_BOOTSTRAP_TOKEN: ${AK_BOOTSTRAP_TOKEN}
      AUTHENTIK_BOOTSTRAP_EMAIL: you@YOUR_DOMAIN

Verify the token – no matter which route produced it:

curl -s -H "Authorization: Bearer YOUR_LONG_RANDOM_TOKEN" \
  https://YOUR_DOMAIN/api/v3/core/users/me/

{"user":{"username":"akadmin", … "is_superuser":true, …}}

2. Route A: forward auth for services without a login

The proxy provider is Authentik’s answer to „this app has no user management at all". It comes in several modes; we use forward_single: one application, one provider.

First the IDs of the two default flows (known from part 1):

API=https://YOUR_DOMAIN/api/v3
TOK="Authorization: Bearer YOUR_LONG_RANDOM_TOKEN"

AUTHZ=$(curl -s -H "$TOK" "$API/flows/instances/?slug=default-provider-authorization-implicit-consent" \
  | python3 -c "import json,sys; print(json.load(sys.stdin)['results'][0]['pk'])")
INVAL=$(curl -s -H "$TOK" "$API/flows/instances/?slug=default-provider-invalidation-flow" \
  | python3 -c "import json,sys; print(json.load(sys.stdin)['results'][0]['pk'])")

Then the provider:

curl -s -X POST -H "$TOK" -H "content-type: application/json" "$API/providers/proxy/" -d "{
  \"name\": \"whoami-forwardauth\",
  \"authorization_flow\": \"$AUTHZ\",
  \"invalidation_flow\": \"$INVAL\",
  \"mode\": \"forward_single\",
  \"external_host\": \"https://YOUR_DOMAIN\"
}"

And the application that uses it – it also creates the tile in the user library:

curl -s -X POST -H "$TOK" -H "content-type: application/json" "$API/core/applications/" -d '{
  "name": "whoami (protected)", "slug": "whoami", "provider": 1
}'

The 1 is the pk from the provider call’s response. Both then appear in the overview:

3. Arm the outpost – and the most common trap

A proxy provider does not work alone: an outpost serves it. Authentik ships an embedded outpost that runs inside the server container – you only have to assign the provider to it:

OUT=$(curl -s -H "$TOK" "$API/outposts/instances/" \
  | python3 -c "import json,sys; print(json.load(sys.stdin)['results'][0]['pk'])")
curl -s -X PATCH -H "$TOK" -H "content-type: application/json" \
  "$API/outposts/instances/$OUT/" -d '{"providers": [1]}'

curl -s -X PATCH -H "$TOK" -H "content-type: application/json" \
  "$API/outposts/instances/$OUT/" \
  -d '{"config": {"authentik_host": "https://YOUR_DOMAIN/"}}'

4. Traefik: the forward auth middleware

Now the connection is missing. Traefik asks the outpost before each request – that is what the forwardauth middleware does. On the protected service:

  whoami:
    image: traefik/whoami:v1.12
    restart: unless-stopped
    networks: [proxy]
    labels:
      - "traefik.enable=true"
      - "traefik.http.routers.whoami.rule=Host(`YOUR_DOMAIN`) && PathPrefix(`/whoami`)"
      - "traefik.http.routers.whoami.entrypoints=websecure"
      - "traefik.http.routers.whoami.tls.certresolver=le"
      - "traefik.http.routers.whoami.middlewares=ak-auth"
      - "traefik.http.services.whoami.loadbalancer.server.port=80"
      - "traefik.http.middlewares.ak-auth.forwardauth.address=http://server:9000/outpost.goauthentik.io/auth/traefik"
      - "traefik.http.middlewares.ak-auth.forwardauth.trustForwardHeader=true"
      - "traefik.http.middlewares.ak-auth.forwardauth.authResponseHeaders=X-authentik-username,X-authentik-groups,X-authentik-email,X-authentik-name,X-authentik-uid"

The three decisive lines:

• address points at the outpost – here through the service name server (Authentik reaches it under this alias on the Docker network) on the shared Docker network, so without a detour over the internet. The path /outpost.goauthentik.io/auth/traefik is the Traefik-specific check endpoint.
• trustForwardHeader=true passes the X-Forwarded-* headers along so Authentik knows the originally requested address and can redirect back correctly.
• authResponseHeaders is the actual benefit: Traefik copies these headers from Authentik’s response into the request to your application. Without that line the service is protected but has no idea who is there.

5. Verify that it really protects

First without a login – curl is enough:

curl -s -o /dev/null -w "%{http_code} → %{redirect_url}\n" https://YOUR_DOMAIN/whoami

302 → https://YOUR_DOMAIN/application/o/authorize/?client_id=…&redirect_uri=…%2Foutpost.goauthentik.io%2Fcallback…

A 302 to the Authentik login is the desired result. In the browser the login page appears before the service:

After logging in you are back at /whoami – and the service shows what it receives:

GET /whoami HTTP/1.1
Host: YOUR_DOMAIN
X-Authentik-Email: you@YOUR_DOMAIN
X-Authentik-Groups: authentik Admins
X-Authentik-Name: authentik Default Admin
X-Authentik-Uid: d216e191a6f972c39931a005a7998a68…
X-Authentik-Username: akadmin
X-Forwarded-Proto: https

That is the whole trick: the application has not a single line of login code – and still knows who is sitting in front of it. Services that support header authentication (Grafana with auth.proxy, Paperless, Forgejo with reverse-proxy auth) can turn that straight into a session.

6. Know the limits of forward auth

Before you put everything behind forward auth: the mechanism assumes a browser. An unauthenticated request gets a 302 redirect to a login form – and that is exactly what breaks anything that is not a browser:

• Mobile apps (Nextcloud, Immich, Audiobookshelf) cannot do anything with the redirect. They see HTML instead of JSON and report „server unreachable". For such services OIDC is the only sensible route – or you exempt the app’s paths deliberately.
• API access and scripts (curl, backup jobs, webhooks) run into nothing. Wherever a service is addressed by token, that path has to bypass the middleware – or you move the protection to an IP allowlist.
• WebDAV and sync clients behave like APIs, with the same outcome.

For such exceptions you create a second router without the auth middleware that serves only the necessary path – and protect it differently, for example with the application’s own token. Example for an API path:

      - "traefik.http.routers.app-api.rule=Host(`YOUR_DOMAIN`) && PathPrefix(`/api`)"
      - "traefik.http.routers.app-api.entrypoints=websecure"
      - "traefik.http.routers.app-api.tls.certresolver=le"
      - "traefik.http.routers.app-api.middlewares=rate@file"

For completeness, the third mode of the proxy provider: forward_domain. With it one outpost serves all services of a domain (*.YOUR_DOMAIN), and users sign in once for all of them. That is the more convenient setup from roughly three services onwards, but it requires Authentik and all applications to live under the same parent domain so the session cookie can be shared. What is tested here is forward_single – switching only affects the provider’s mode and the cookie domain.

7. Route B: OpenID Connect for services with their own SSO

If the application has an OIDC login, that is the better route: it then keeps real user accounts including roles instead of just seeing a name in a header.

Create the provider – what matters is the redirect URI, which must match the application’s callback address exactly (Grafana as an example):

curl -s -X POST -H "$TOK" -H "content-type: application/json" "$API/providers/oauth2/" -d "{
  \"name\": \"grafana-oidc\",
  \"authorization_flow\": \"$AUTHZ\",
  \"invalidation_flow\": \"$INVAL\",
  \"client_type\": \"confidential\",
  \"redirect_uris\": [{\"matching_mode\": \"strict\", \"url\": \"https://GRAFANA_DOMAIN/login/generic_oauth\"}]
}"

The response contains client_id and client_secret – you need both in the application. Then create an application pointing at this provider, as above.

Whether everything lines up is revealed by the discovery document. Authentik publishes it per application under its slug:

curl -s https://YOUR_DOMAIN/application/o/grafana/.well-known/openid-configuration \
  | python3 -m json.tool | head -12

"issuer": "https://YOUR_DOMAIN/application/o/grafana/",
"authorization_endpoint": "https://YOUR_DOMAIN/application/o/authorize/",
"token_endpoint": "https://YOUR_DOMAIN/application/o/token/",
"userinfo_endpoint": "https://YOUR_DOMAIN/application/o/userinfo/",

Note: the issuer is application-specific (it contains the slug), while the remaining endpoints are the same for all applications. Exactly these addresses – or the discovery URL itself if the app supports it – go into the application. For Grafana, for instance:

GF_AUTH_GENERIC_OAUTH_ENABLED=true
GF_AUTH_GENERIC_OAUTH_NAME=Authentik
GF_AUTH_GENERIC_OAUTH_CLIENT_ID=YOUR_CLIENT_ID
GF_AUTH_GENERIC_OAUTH_CLIENT_SECRET=YOUR_CLIENT_SECRET
GF_AUTH_GENERIC_OAUTH_SCOPES=openid profile email
GF_AUTH_GENERIC_OAUTH_AUTH_URL=https://YOUR_DOMAIN/application/o/authorize/
GF_AUTH_GENERIC_OAUTH_TOKEN_URL=https://YOUR_DOMAIN/application/o/token/
GF_AUTH_GENERIC_OAUTH_API_URL=https://YOUR_DOMAIN/application/o/userinfo/

8. Who may do what? Restricting access

As long as no policy is attached to an application, every signed-in user may use it. For the normal case you bind a group to the application: Applications → your application → policy / group / user bindings, then pick the group.

Only after that does the tile disappear from the user library for everyone else – and access is blocked. The most honest way to verify is with a second test account that is not in the group: it should neither see nor be able to open the application.

When things go wrong

Your problem is not listed? Search all error messages →

Maintenance & backups

Spot-check after every Authentik update. An update can change flows and providers; the integrations themselves are robust, but the quick test is worth it: curl on the protected path must still return 302, and the discovery document must show your endpoints. Two commands that keep a login from being silently broken for weeks.

Client secrets belong in the password manager. They live in the application (environment variables) and in Authentik. If one is regenerated, the other side has to follow – note down which app uses which secret when you create it, otherwise you will be searching in both systems later.

The database matters even more now. Providers, applications and group bindings all live in PostgreSQL. The pg_dump from part 1 is no longer a nice-to-have: without it you rebuild every integration after an outage. Back it up daily with Restic.

Keep the emergency exit open. Every service behind forward auth is only as reachable as Authentik. Keep a local account in important applications – and put no tools behind SSO that you need for repairs; that applies especially to Dockge and similar management interfaces. Monitoring on /-/health/ready/ notices the outage before your users do.

Tidy up tokens. The bootstrap token from step 1 is an admin access without a second factor. Once the setup is in place, delete it under Directory → Tokens – and create a dedicated token with limited rights for later automation.

What are we building?

At the end, Authentik 2026.8.3 runs behind your Traefik at https://YOUR_DOMAIN – your own identity provider with PostgreSQL on an internal network. You have an administrator account, you know how flows, stages and providers fit together, and you can create users and groups.

Two things that many guides still show differently, and that will save you work:

• Redis is no longer needed. Current Authentik versions keep cache and websocket channels in PostgreSQL – visible in the startup log as the migrations django_postgres_cache and django_channels_postgres. The stack now consists of PostgreSQL, server and worker only.
• Resource usage is modest. Measured while idle right after setup: server 312 MiB, worker 197 MiB, PostgreSQL 42 MiB – around 550 MiB RAM in total. The frequently quoted „at least 2 GB" is a recommendation with headroom, not a starting figure.

Why Authentik – and when something else?

The three usual candidates differ mainly in weight:

• Authentik ships a full web interface with user management, groups, an event log and protocols from OIDC to LDAP. That is a lot of functionality – and the reason it needs a database and a worker.
• Authelia is considerably lighter, configured through YAML files, and has no user management in the browser. If you want to protect two or three services and like keeping configuration in files, it is the leaner choice.
• Keycloak is the heavyweight from the Java world, powerful in enterprise contexts, but with matching resource and learning costs.

For a self-operated stack with a handful of services and the wish to manage users in a browser, Authentik is the best compromise. If you only have a handful of static users and no appetite for a database, Authelia gets you there faster.

Prerequisites

• A server running Debian 13 with Docker (tested: netcup VPS, Docker 29.6.1, Compose v5.3.1)
• At least 2 GB RAM for the server overall – Authentik takes around 550 MiB, but database maintenance and load spikes during many logins need headroom
• A running Traefik with its proxy network (guide)
• A dedicated subdomain, e.g. auth.YOUR_DOMAIN (connecting a domain)
• An understanding of Docker networks – we deliberately separate the public and the internal network here

Step by step

1. Create directories and secrets

mkdir -p /opt/authentik/{media,certs,custom-templates} && cd /opt/authentik
chmod 755 media certs custom-templates

That chmod is not cosmetic. If you have hardened your server with a stricter umask – such as UMASK 027 in /etc/login.defs, as the Lynis audit (Tutorial expected in October) recommends – mkdir creates drwxr-x---. The Authentik container runs as user 1000 and cannot enter directories like that. With chmod 755 it works regardless of the umask:

without chmod (drwxr-x---)   /if/flow/initial-setup/  ->  HTTP 500
with    chmod (drwxr-xr-x)   /if/flow/initial-setup/  ->  HTTP 200

The nasty part: the health endpoint /-/health/ready/ answers 200 in both cases. The container counts as healthy while the interface serves nothing but errors.

Authentik needs two secrets: a database password and a SECRET_KEY that signs sessions and tokens. Generate both randomly and put them into an .env:

{
  echo "PG_PASS=$(openssl rand -base64 36 | tr -d '\n=+/')"
  echo "AUTHENTIK_SECRET_KEY=$(openssl rand -base64 60 | tr -d '\n')"
} > .env
chmod 600 .env

2. The Compose file with separated networks

The layout follows the pattern from understanding Docker networks: only the server is attached to the public proxy network, while the database and the worker live on an internal network with no internet access. Create /opt/authentik/compose.yaml and replace YOUR_DOMAIN:

services:
  postgresql:
    image: postgres:16-alpine
    restart: unless-stopped
    healthcheck:
      test: ["CMD-SHELL", "pg_isready -d $${POSTGRES_DB} -U $${POSTGRES_USER}"]
      interval: 30s
      timeout: 5s
      retries: 5
      start_period: 20s
    environment:
      POSTGRES_DB: authentik
      POSTGRES_USER: authentik
      POSTGRES_PASSWORD: ${PG_PASS}
    volumes:
      - database:/var/lib/postgresql/data
    networks: [intern]

  server:
    image: ghcr.io/goauthentik/server:2026.8.3
    restart: unless-stopped
    command: server
    depends_on:
      postgresql:
        condition: service_healthy
    environment:
      AUTHENTIK_SECRET_KEY: ${AUTHENTIK_SECRET_KEY}
      AUTHENTIK_POSTGRESQL__HOST: postgresql
      AUTHENTIK_POSTGRESQL__NAME: authentik
      AUTHENTIK_POSTGRESQL__USER: authentik
      AUTHENTIK_POSTGRESQL__PASSWORD: ${PG_PASS}
      AUTHENTIK_ERROR_REPORTING__ENABLED: "false"
      AUTHENTIK_LISTEN__TRUSTED_PROXY_CIDRS: 172.16.0.0/12
    volumes:
      - ./media:/media
      - ./custom-templates:/templates
    shm_size: 512mb
    networks: [proxy, intern]
    labels:
      - "traefik.enable=true"
      - "traefik.http.routers.authentik.rule=Host(`YOUR_DOMAIN`)"
      - "traefik.http.routers.authentik.entrypoints=websecure"
      - "traefik.http.routers.authentik.tls.certresolver=le"
      - "traefik.http.services.authentik.loadbalancer.server.port=9000"

  worker:
    image: ghcr.io/goauthentik/server:2026.8.3
    restart: unless-stopped
    command: worker
    user: root
    depends_on:
      postgresql:
        condition: service_healthy
    environment:
      AUTHENTIK_SECRET_KEY: ${AUTHENTIK_SECRET_KEY}
      AUTHENTIK_POSTGRESQL__HOST: postgresql
      AUTHENTIK_POSTGRESQL__NAME: authentik
      AUTHENTIK_POSTGRESQL__USER: authentik
      AUTHENTIK_POSTGRESQL__PASSWORD: ${PG_PASS}
      AUTHENTIK_ERROR_REPORTING__ENABLED: "false"
    volumes:
      - /var/run/docker.sock:/var/run/docker.sock
      - ./media:/media
      - ./certs:/certs
      - ./custom-templates:/templates
    shm_size: 512mb
    networks: [intern]

volumes:
  database:

networks:
  proxy:
    external: true
  intern:
    internal: true

Four points that matter here:

• loadbalancer.server.port=9000 – internally Authentik listens on 9000 (HTTP). Its own HTTPS port 9443 stays unused: TLS is Traefik’s job.

• shm_size: 512mb comes from the official reference and prevents memory errors on larger database queries.

• user: root plus the Docker socket on the worker are needed so Authentik can later manage its own “outposts” as containers. The socket is deliberately not mounted :ro here: Authentik has to create, kill and remove containers, and that only works with write access. If you don’t need outpost management, drop the socket.

  Write access to the Docker socket is effectively root on the host, though. Authentik therefore recommends putting a Docker socket proxy in front of it, allowing only the API calls actually needed (create, read, kill and remove containers, query the version). On a server that does more than run Authentik, that is worth the effort.

• AUTHENTIK_ERROR_REPORTING__ENABLED: "false" turns off error reporting to the project. It is on by default; for privacy-friendly operation it belongs off.

• AUTHENTIK_LISTEN__TRUSTED_PROXY_CIDRS has been mandatory behind a reverse proxy since 2026.8. Authentik now only honours X-Forwarded-Proto, X-Forwarded-Host and X-Forwarded-For when the connection comes from a network listed here – this prevents forged proxy headers. Enter the Docker network Traefik connects from (Docker allocates from 172.16.0.0/12 by default). Without it, Authentik builds redirects to http:// instead of https:// and the interface hangs on an endless loading spinner. Find your Traefik’s exact address with docker network inspect proxy.

3. Start it and wait for the migrations

cd /opt/authentik && docker compose up -d

On the first start Authentik creates its database schema – over 70 migrations, and that takes a while. The health endpoint makes the progress observable:

curl -s -o /dev/null -w "%{http_code}\n" https://YOUR_DOMAIN/-/health/ready/

While the migrations run it answers 404; once Authentik is ready, 200. On the VPS 1000 that most recently took just under two minutes. The setup flow follows a few seconds later – the worker only imports the bundled flows afterwards; in the test it was reachable 15 seconds after the first 200. In parallel, the container states:

docker compose ps --format "{{.Name}}\t{{.Status}}"

authentik-postgresql-1   Up 27 seconds (healthy)
authentik-server-1       Up 21 seconds (health: starting)
authentik-worker-1       Up 21 seconds (healthy)

4. Create the administrator account

Now the step where many people stumble: open the root address, i.e. https://YOUR_DOMAIN/. From there Authentik redirects you into the setup flow.

If you call the flow directly (/if/flow/initial-setup/), Authentik refuses with „request denied – Access the authentik setup by navigating to https://…/". That is not a mistake in your configuration but intentional.

Enter the email address and a very long password. Two things worth knowing:

• The username of the account created here is akadmin – not your email address.
• The interface appears in your browser’s language.

After submitting you land in the user interface (/if/user/) – the view all your users will see later: a tile library of the applications they are allowed to use.

5. The administrator interface

Administration lives at https://YOUR_DOMAIN/if/admin/ – or via the button in the top right:

Four tiles answer the typical operational questions:

• System status – „everything is operational" means: database reachable, no open warnings.
• Version – the running version. If it says the latest version is unknown, Authentik could not perform the version check; with restricted outbound traffic that is normal.
• Workers – must be at least 1. If it says 0, the worker is not running, and then a lot silently does not happen: no emails, no certificate rotation, no scheduled tasks.
• Latest events – every login and change with user, time and client IP. This is your audit log and the first place to look for „who changed that?".

6. Understanding the model: flows, stages, providers, applications

Authentik is not a login form but a construction kit. Once you know these terms you find your way around the interface immediately – and you understand the error messages.

• Stage – a single step: ask for a password, check a TOTP code, obtain consent, write a user. A stage can do nothing on its own.
• Flow – a chain of stages for one purpose. Authentik ships ready-made ones, visible in the list: default-authentication-flow (login, 4 stages), default-invalidation-flow (logout), default-source-enrollment (enrollment through an external source), plus flows for setting up TOTP and static recovery codes.
• Policy – a condition deciding whether a stage applies or access is allowed: „only members of this group", „only from this network", „only with a confirmed email".
• Provider – the technical interface to one service: OAuth2/OpenID Connect, SAML, LDAP or the proxy provider for applications without their own login.
• Application – the bracket around it: it connects a provider with permissions and creates the tile in the user library.
• Outpost – an outsourced component Authentik operates itself (for the proxy provider, for instance). That is exactly why the worker needs the Docker socket.

For everyday use that means: you do not touch the default flows. You create one provider plus one application per service – and that is precisely the content of part 2.

What actually happens during a login can be read off the default flows. When a user opens a protected service, the default-authentication-flow runs with its four stages:

1. Identification – who are you? (username or email, depending on the setting)
2. Password – checked against the stored password
3. Authenticator validation – if there is a second factor, it is demanded here
4. User login – the session is created

After that the authorization flow takes over: it decides whether this user may use this application (default-provider-authorization-explicit-consent asks for consent once, …-implicit-consent skips the question). On logout the invalidation flow applies.

If something goes wrong later, that order is your search aid: if the user gets stuck at the password, it is a problem in the authentication flow. If they get through but don’t see the application, it is authorization – so permissions or policies.

7. Create users and groups

Under Directory → Users you create accounts. The important distinction:

• Users have a username, name, email and optionally attributes.
• Groups bundle users – and you attach the permissions for applications to groups. So create groups right away (family, admins) instead of granting rights per user. Otherwise you maintain the same list ten times over for ten services.

You then use the akadmin account for administration only; for everyday use you create yourself a normal account. That is the same separation as „don’t work as root".

8. Harden Authentik itself

From now on the identity provider is the most rewarding target on your server. Four measures that cost little together:

• Put a rate limit and security headers in front of it. Authentik has its own reputation checks, but the first brake belongs on the reverse proxy. Attach the middlewares from hardening Traefik to the router – a rate limit makes password guessing unattractive before the request even reaches Authentik.
• Restrict the administration interface. You rarely need /if/admin/, and rarely while travelling. An IP allowlist or access only through WireGuard is appropriate here – without restricting the normal login path for your users.
• Make a second factor mandatory, at least for administrators. In Authentik that hangs off the authenticator validation stage of the login flow.
• Leave error reporting off – already set in the Compose file above. By default Authentik sends error reports to the project; for a service that sees every credential in your environment, that belongs switched off.

When things go wrong

Your problem is not listed? Search all error messages →

Maintenance & backups

Updates are mandatory here. The project releases frequently – the 2026.8 line saw several patch releases within a few weeks. Because Authentik is the master key to every attached service, you want security fixes promptly:

cd /opt/authentik && docker compose pull && docker compose up -d

Read first, then update. Authentik uses date-based versions (2026.8.3). Between minor versions (2026.2 → 2026.5) there are regularly changes that need manual work; the release notes name them explicitly. Never jump across several minor versions at once, and take a backup first: the database is migrated on start, and that is not easily reversible.

What belongs in the backup:

• .env – contains the SECRET_KEY and the database password. Without the key the rest is worthless.

• The PostgreSQL database – it holds users, groups, flows, providers and applications. Back it up not as a file copy of the volume but as a dump:

  Terminal

  docker compose exec -T postgresql pg_dump -U authentik authentik \
    | gzip > /opt/backup/authentik-$(date +%F).sql.gz

• media/ – uploaded logos and icons. Small, but annoying to reconstruct.

Restic then picks up the dump. Why not a volume copy: you don’t copy a running database file by file – that produces inconsistent backups which only reveal themselves when you try to restore.

Plan for the outage. If Authentik is down, nobody gets into the attached services – that is the flip side of single sign-on. Two precautions cost little: keep a local emergency account in every attached service that works without SSO, and add Authentik to your monitoring – ideally with a check on /-/health/ready/, which tests exactly what matters.

Tidy up users and groups. An identity provider grows with you: guests, old accounts, test users. Take a look at the user list twice a year and deactivate what is no longer needed – deactivating beats deleting, because otherwise your event logs develop gaps.