Infrastructure guide
Authentik Docker Compose: Protect the Identity Provider First
Deploy authentik from its versioned Compose file with safe secrets, restricted Docker access, HTTPS, backups, and break-glass recovery.
Published and reviewed by OpenAlt · October 1, 2026
OpenAlt’s verdict: run authentik Docker Compose only when you can recover the identity provider as deliberately as the applications it protects. Self-hosting preserves control, but makes availability, secrets, upgrades, and break-glass access your responsibility. Start narrow, document recovery, and avoid placing every administrative path behind one untested login.
Table of Contents
- The identity provider must be more recoverable than protected apps
- Preflight resources, domain, TLS, email, time, break-glass and rollback
- Versioned official Compose and safe secret generation
- Server, worker, PostgreSQL and Docker socket risk
- HTTPS and initial setup without careless admin exposure
- One low-risk app first, bindings, groups, MFA and recovery
- Back up database, media, config and secrets; prove restore
- Versioned upgrades, monitoring and break-glass drills
- FAQ
1. The identity provider must be more recoverable than protected apps
An identity provider deserves stronger recovery than any single protected application because its failure can block access to many systems at once. Treat authentik as critical infrastructure: preserve an independent administrative route, keep recovery material offline, and rehearse restoration before broad rollout. The goal is fewer irreversible dependencies, not perfect uptime.
Use two layers of access:
- Normal user authentication for everyday administration.
- An independent break-glass path that does not depend on the same protected applications.
- A written rollback route for configuration, upgrades, and proxy changes.
- Recovery material stored separately from the host running Compose.
The official backup and restore guidance should define the recovery conversation. Before broad SSO, administrators should be able to explain what is restored, where it is restored, and how access returns during an outage.
2. Preflight resources, domain, TLS, email, time, break-glass and rollback
Preflight should establish whether the deployment is supportable before any login depends on it. Confirm the documented baseline of 2 CPU, 2 GB RAM, and Compose v2. Then settle the hostname, HTTPS path, email delivery, clock alignment, break-glass access, and rollback owner. If one remains unclear, delay onboarding.
| Gate | Evidence to keep before launch |
|---|---|
| Resources | At least 2 CPU and 2 GB RAM planned |
| Compose | Compose v2 available and version recorded |
| Domain and TLS | Stable hostname and deliberate HTTPS termination |
| Email and time | Email configuration documented; system clocks aligned |
| Recovery | Break-glass path and rollback owner written down |
The official Docker Compose installation guidance supplies the resource and Compose requirements. Email belongs in the deployment plan; the configuration documentation covers Compose environment and email configuration.
3. Versioned official Compose and safe secret generation
Start from the official Compose file and make the version choice explicit so the setup remains reviewable. Treat generated secrets as deployment inputs, preserve them securely, and avoid the deprecated latest tag. The file, image version, and secret-handling method should change together under a rollback-friendly record.
A practical sequence is:
- Obtain the official Compose definition.
- Record the chosen image version and the date it entered service.
- Generate secrets using the documented mechanism.
- Store the Compose file and secret inventory in a restricted recovery location.
- Keep the previous known-good version available for rollback.
The first-steps documentation warns against the deprecated latest tag and covers initial bindings and upgrades. The Docker Compose documentation describes generated secrets, so generation should remain part of the documented deployment process.
4. Server, worker, PostgreSQL and Docker socket risk
Review the server, worker, PostgreSQL data, and Docker socket as separate risk decisions, even when Compose starts them together. State, background work, application access, and container-control privileges need distinct owners and recovery notes. A compact deployment is not automatically simple when one identity service controls access elsewhere.
Ask:
- What data must survive a server replacement?
- Which configuration changes affect the worker or database?
- Which services require network access, and which should remain private?
- Does the deployment need Docker socket access, and what would it allow?
The official Compose guidance identifies Docker socket risk. Do not treat a socket mount as harmless plumbing. If required, document why, restrict surrounding access, and include it in recovery and rollback planning.
5. HTTPS and initial setup without careless admin exposure
Initial exposure should be narrow, encrypted, and deliberate: publish only the required entry path, establish HTTPS, and complete first steps before inviting applications. The documented Compose ports are 9000 and 9443, so decide which proxy or binding owns public traffic and which remains restricted rather than exposing both by habit.
A sensible sequence is:
- Bind the service to the intended hostname and HTTPS path.
- Limit administrative access while first configuration is completed.
- Confirm the configured entry points before connecting an application.
- Record proxy, certificate, and binding assumptions for rollback.
The official installation guidance lists ports 9000 and 9443. The first-steps guide covers starting with the official file and configuring bindings. The exact proxy arrangement remains an operational choice.
6. One low-risk app first, bindings, groups, MFA and recovery
Onboard one low-risk application first, then let access policy earn its complexity. Use bindings and groups to express who should reach it, require MFA where policy calls for it, and keep recovery paths independent of that application. Expand only after ordinary login and break-glass recovery are understood.
For the first application:
- Choose a service whose outage has limited consequences.
- Define the smallest useful group membership.
- Make the binding explicit instead of relying on accidental defaults.
- Decide which users need MFA and document the exception path.
- Confirm that administrators can recover access without that application.
The first-steps documentation includes bindings and upgrades, while the configuration documentation covers Compose environment and email configuration. Keep policies simple enough to explain during an incident.
7. Back up database, media, config and secrets; prove restore
Recovery is credible only when the backup set includes the database, media, configuration, and secrets, with a restore path for each. Use the official backup-and-restore scope as the boundary, then perform a controlled restore exercise with a separate destination or maintenance window before trusting the system with more applications.
Identify:
- Database backup location and retention.
- Media backup location and retention.
- Configuration required to recreate the deployment.
- Secret custody, access, and replacement procedure.
- The person or role responsible for restoring service.
The official backup and restore documentation is the source of truth for supported scope. A backup that cannot be located, decrypted, or applied is not a recovery plan. Keep the restore record with deployment documentation and update it after meaningful changes.
8. Versioned upgrades, monitoring and break-glass drills
Treat upgrades, monitoring, and break-glass drills as one operating loop: version deliberately, watch the identity path, and rehearse access when normal authentication is unavailable. The official first-steps guidance calls out bindings and upgrades; use it as the change-control anchor while OpenAlt’s adjacent infrastructure guides shape entry and alerting paths.
Keep the rhythm repeatable:
- Record every version change and its rollback point.
- Review bindings after upgrades or major configuration changes.
- Monitor the identity path, database dependency, and proxy entry point.
- Reconfirm break-glass access on a schedule.
- Remove abandoned application bindings and administrative routes.
For ingress patterns, see OpenAlt’s Traefik Docker Compose guide or Caddy Docker Compose guide. For adjacent practices, browse the monitoring category and password manager category. The official upgrade guidance remains authoritative for authentik changes.
FAQ
Is authentik self hosted suitable for a small team?
Yes, if the team accepts responsibility for recovery, secrets, upgrades, and break-glass access. The documented baseline is modest, but operational simplicity comes from disciplined scope rather than assuming the identity provider can fail safely.
Should both documented ports be exposed publicly?
No. The Compose documentation lists 9000 and 9443. Choose the intended HTTPS and proxy arrangement, restrict unnecessary bindings, and document the decision. Public exposure should follow the required entry path, not the list of available ports.
Are generated secrets enough for recovery?
No. Generated secrets are only one recovery input. Preserve them with the database, media, and configuration, then follow the official backup-and-restore scope. Recovery also requires custody, access, and a written restore route.
What should happen before adding more applications?
Confirm that the initial binding, group policy, MFA decision, normal login, and independent recovery path are understood. Then add applications gradually, retaining version records and rollback notes so one policy mistake does not become an identity-wide outage.