authentik Docker Compose production setup

When authentik on Docker Compose is enough for production

Docker Compose is enough for a small production authentik deployment when one team owns the host, the user population is modest and a short outage for patching is acceptable. If you need self-managed single sign-on for a handful of applications and your team can run one Linux host with backups, Compose fits. If you expect high availability requirements, several teams deploying their own infrastructure, or frequent scaling changes, plan for Kubernetes from the start. The authentik Docker Compose guide itself positions Compose for test setups and small-scale production, and its stated minimum of 2 CPU cores and 2 GB of RAM is a floor, not a sizing target.

A standard authentik deployment runs three components. The server container runs core with an embedded outpost, which handles sign-in and the protocols your applications use. The worker container runs background tasks such as email and scheduled jobs. PostgreSQL stores all configuration and data except uploaded files. Because PostgreSQL is the only stateful database, the host's real single point of failure is the database volume and the host itself, so ask who restores it and how quickly. Since authentik 2025.10, Redis is no longer used, which means Compose has one fewer service to run but a larger PostgreSQL connection load to plan for.

The open-source edition is MIT-licensed for most of the code, while the code under authentik/enterprise/ is governed by a separate enterprise license. This page assumes the open-source feature set. Google Workspace and Microsoft Entra ID integrations, mTLS client certificate authentication, privileged access management, password history and enhanced audit logging are listed as enterprise-only on the authentik pricing page, so confirm early whether your requirements depend on any of them. If they do, the Compose decision should be made together with the licensing decision, and you should confirm the current terms directly with authentik before you design around them.

Deployment options and when each fits

This table compares four ways to run authentik and shows which team size, availability need and operating skill each one suits. Read it as a decision aid: start with the row for your team's operating skills, then check the availability and patching rows before choosing. The main takeaway is that Compose on one host is a reasonable small production choice only when someone owns patching, backups and restores.

Option	Best fit	Main trade-off	Who owns patching and backups
Single Docker host with Compose (bundled PostgreSQL in the stack)	Small team, one site, limited identity load, staff comfortable with Docker hosts	One host is a single point of failure; restores depend on your own backup routine	Your team owns host OS, Docker, authentik image updates and PostgreSQL backups
Compose with external managed PostgreSQL	Small team that wants database backups and failover handled by a managed service	Adds a cloud or hosting dependency, network path and credentials to manage	Your team owns the host and authentik; the database provider owns database maintenance tasks it documents
Helm chart on Kubernetes with external PostgreSQL	Teams already running Kubernetes with platform staff and rolling upgrade practice	The chart's bundled PostgreSQL is for demonstration and testing, so you must provision and run a separate database	Platform team owns the cluster, chart upgrades and ingress; database owner handles PostgreSQL
AWS CloudFormation template	Teams already on AWS that want managed compute, load balancing and multi-zone database layout	Ties the deployment to AWS services and their cost model, and requires AWS skills to change	Your team owns the stack parameters and upgrades; AWS manages the underlying services you select
Compose on one host, minimum baseline	Lab, pilot or low-load production	Guide baseline is at least 2 CPU cores and 2 GB of RAM; size up for real login volume	Confirm sizing with the Compose installation guide before go-live

How to set up authentik on Compose for production

This sequence takes a small host from sizing check to a working authentik instance behind TLS, with the storage mount set for the current release line. Each step closes with a check so you know it is safe to move on.

Confirm host sizing against the documented minimum
Before anything is installed, confirm the host meets the minimum the official Compose guide describes: at least 2 CPU cores and 2 GB of RAM. The guide positions Compose for test setups and small-scale production, so treat these numbers as a floor and size up for your user count, login volume and the number of applications you protect. Confirm the host's OS, Docker Engine and Compose plugin versions against the current guide, and make sure the host has a stable DNS name and outbound access to pull images, or a plan for mirroring them. The step is done when the host passes these checks and you can pull a test image from your registry path.
Download the compose file from the official guide
Fetch the Compose file from the official Docker Compose installation guide rather than copying an older example from a blog or forum. Pin the release you intend to run, using the version named in the guide and in the project's release list, and record that choice in your change log. Keep the file in a dedicated directory owned by the account that runs the stack, and store that directory in version control without any secrets in it. The step is done when docker compose config renders the file without errors, which confirms the YAML and variable references are valid before you add any values.
Create the .env file with generated secrets
Create a .env file next to the compose file and generate the secret key and the PostgreSQL password with a cryptographically secure random generator, not by hand. Set the PostgreSQL credentials and the secret key as variables the compose file reads, and set the public URL that users will reach. Restrict the file's permissions so only the operator account can read it, and add .env to .gitignore before the first commit. Store a copy of the secrets in your organization's password manager or secrets store, because losing the secret key can make encrypted data unrecoverable. The step is done when the file exists with restricted permissions and git status does not list it.
Set the storage mount for your release
Set the storage mount according to the version you pinned. From authentik 2025.12, local file storage expects a mount at /data, and the existing /media mount moves to /data/media, with files served from /files instead of /media. For a new install, define the volume at /data on both the server and worker services. For an existing install on a release before 2025.12, stop the stack, copy the contents of the old media volume into the new location under /data/media, update the volume definitions in the compose file to match, and check the release notes for any other path changes before starting. The step is done when docker compose config shows the /data mount on both services and the old /media path no longer appears in the file.
Start the stack and check container health
Start the stack with docker compose up -d and watch the output of the server and worker containers, along with the PostgreSQL container. The server runs core with an embedded outpost, the worker handles background tasks, and PostgreSQL holds configuration and data except uploaded files. Authentik no longer uses Redis as of the 2025.10 release line, so do not add a Redis service from older examples. Check that all three containers report healthy status and that the server logs show the web listener starting without database errors. The step is done when docker compose ps lists every service as running or healthy and the logs contain no repeated restart or connection errors.
Complete the initial administrator setup
Open the initial setup path on the public URL and create the first administrator account, using a strong password stored in your secrets manager and a named, individual identity rather than a shared account. Enable multi-factor authentication on that administrator account before you add any applications. Keep the bootstrap process in mind: if you automate installs, confirm the bootstrap settings for your release in the project documentation before storing any password in configuration. Record the administrator in your access review process. The step is done when you can sign in as the new administrator, complete the MFA enrollment, and see the admin interface load without certificate or mixed-content warnings.
Place a reverse proxy with TLS in front
Put a reverse proxy in front of the server with a valid TLS certificate for the public hostname, and forward the headers authentik needs to build correct redirect and cookie behavior. Confirm the proxy forwards WebSocket connections, because the admin and flow interfaces depend on them. Expose only the proxy's HTTPS port publicly, and restrict direct access to the authentik container's port to the proxy's network. Confirm the public URL in authentik matches the hostname the proxy serves, since mismatches are a common cause of login loops. The step is done when the hostname loads over HTTPS with a trusted certificate, the sign-in page works through the proxy, and the redirect after login lands on the correct host.
Verify logins and file uploads end to end
Test the instance the way users will use it. Sign in with a non-administrator test account, complete the enrollment and MFA flow, and sign out and back in. Then upload a file that uses local storage, such as a custom application icon or a branding image, and confirm it saves and displays after a page reload. Check that the file is served from the /files path and that it persists after you restart the stack, which proves the /data mount is working. Review the server and worker logs for errors generated by these tests. The step is done when the test login succeeds, the upload persists across a restart, and the logs show no new errors. Schedule backups of the PostgreSQL database and the /data volume before you put real users on the system.

What changes for the /data mount since 2025.12

From authentik 2025.12, uploaded files are served from /files instead of /media, and local file storage expects a volume mounted at /data. If your existing Compose file mounts a volume at /media, that mount has to move so the files land at /data/media. Before you pull a 2025.12 or later image, open the server and worker services in your docker-compose.yml, find every volume that points at /media, and change the container side of the mapping to /data/media. Make the same change on both services, because both need to read and write the same files. Confirm the exact behavior against the authentik 2025.12 release notes before you edit the file, and check whether your version of the compose file already reflects the new path.

The data affected by this change is uploaded files: application icons, brand logos, background images and similar assets that administrators upload through the interface. Everything else, including users, groups, providers, applications, flows, policies and audit history, is stored in PostgreSQL, which the architecture documentation describes as holding all configuration and data except uploaded files. That split is why a mount mistake usually shows up as broken images or missing assets rather than lost accounts. It is also why the database backup alone does not cover uploads: you need a copy of the host directory behind the /media or /data volume as well.

Plan the change as part of the upgrade, not as a separate step. Take a database dump and a copy of the file volume, then bring up the new version on a staging copy of your Compose project with the adjusted mount. Log in, open an application that has an icon and a branding setting that uses an uploaded image, and confirm both still render. If a file is missing, stop before touching production: the file most likely sits in the old path on the host and needs to be moved into the new directory layout. Ask your team to confirm the host paths in your own environment, since the mount location is set by your Compose file and host layout, not by authentik.

Securing secrets, network exposure and admin access on a single host

A Compose deployment puts the authentik server, worker, and database on one machine, so a single gap in secrets, exposure, or patching affects every sign-in. The cards below cover the controls to set before go-live and the checks to repeat after each upgrade.

Keep secrets in a restricted .env file

The secret key and database password live in the .env file beside the compose file. Set owner-only read permissions on that file, keep it out of version control, and confirm that both the server and worker containers receive the same secret key. Rotating the secret key after a leak invalidates existing sessions and tokens, so plan that step before you need it. Ask who on your team can read the host and the backup copies of this file.

Keep PostgreSQL off public interfaces

The compose file publishes services, and the database should never be one of them. Confirm that no PostgreSQL port is bound to a public address, and that the host firewall blocks it from outside. Only the authentik containers on the internal Compose network should reach the database. Check this with a port scan from outside your network after every change to the compose file.

Terminate TLS at a reverse proxy

Put a reverse proxy in front of authentik to handle certificates and HTTPS redirects. The proxy must send the forwarded headers authentik expects, and it should overwrite client-supplied values rather than pass them through. Wrong forwarded headers cause wrong client IPs in logs and broken redirect URLs. Test a login from a browser and inspect the issuer URL in an OIDC discovery response.

Restrict admin interface access

The admin interface can change providers, flows, and users, so it should not be reachable from the open internet. Limit access to a management network, VPN, or an allowlist at the proxy, and keep end-user login paths separate from admin paths. Review who holds superuser rights and remove unused accounts. Ask your team to confirm which paths the proxy exposes publicly before go-live.

Patch the host and pinned images

The host operating system, Docker Engine, and the authentik images all need regular updates. Pin the authentik image to a specific release tag rather than a floating tag, so upgrades happen on purpose. Schedule host patching with a maintenance window and take a database backup before each change. Check the releases page for each new version so you know what changed.

Follow the supported version policy

authentik publishes a security policy that lists which versions receive security fixes, and it announces security releases at least 24 hours in advance. Subscribe to release notices and record the supported version lines in your operations runbook. Plan the time to move to a supported line before the current one falls out of support. Ask your team who receives the advance notice and who acts on it.

Backing up and upgrading a Compose deployment

Every Compose deployment needs three backup sets before the first upgrade: a PostgreSQL dump or volume snapshot, the /data directory holding uploaded files, and the .env file that carries the secret key and database credentials. PostgreSQL stores all configuration and data except uploaded files, so the database is the most important of the three. Keep the .env file in a secure store with access limited to the people who run the stack, because losing AUTHENTIK_SECRET_KEY can make encrypted data unrecoverable. Take the database backup and the file backup at the same point in time, or pause writes first, so the two sets match each other.

Treat a restore test as a required step, not an optional check. Restore the database dump and the /data contents into a separate host or Compose project, start authentik, and confirm that an administrator can sign in, that a test application still resolves, and that an uploaded icon or background renders. Record how long the restore took, since that figure is the recovery time you can actually promise. Before any upgrade, read the release notes for every version between your current release and the target, and check the supported version list in the authentik security policy. Move through versions in the order the project specifies and confirm the target version is still on the supported list.

The 2025.10 release removed Redis and moved caching, tasks, sessions and WebSocket functions to PostgreSQL. The release notes warn of roughly 50% more PostgreSQL connections after upgrading, so an upgrade that crosses that release needs the database sized before the change. Check the connection limit, the memory allocated to PostgreSQL, and the number of server and worker containers, then watch active connections for several hours after the upgrade. If the upgrade also moves files from /media to /data/media (from 2025.12), include that path change in the restore test so uploaded files are not lost during the switch.

Signs it is time to move to Kubernetes or a managed setup

Docker Compose suits small production setups on a single host, and the triggers below show when that single-host model stops matching your availability, scaling and staffing needs. Each one is a question to answer in your own environment, not a fixed threshold, and several often appear together.

Single host failure is unacceptable

Compose runs the server, worker and PostgreSQL on one machine, so a host failure, disk fault or failed upgrade takes sign-in down for every application. Ask whether your users, service owners and auditors can tolerate that outage window, and whether a second host with failover is a requirement. If yes, plan for Kubernetes or a managed cloud service with redundant nodes and a database that survives a node loss.

Workers and servers must scale separately

The server handles sign-in traffic while the worker runs background tasks such as sending email and processing events. If login load or background backlog grows at different rates, you need to scale each independently. Ask whether you can meet that need by sizing one host larger, or whether you need replicas of each component across nodes.

PostgreSQL must be managed separately

Compose usually runs PostgreSQL as a container beside authentik, which ties database backups, patching and major upgrades to the same host. Many organizations require a separately managed database with its own backup policy, access controls and recovery testing. Ask who owns that database, how it is restored, and whether your database team already runs a platform that authentik can point to.

Several environments need repeatable deployment

When you run development, staging and production, hand-edited Compose files and .env values drift apart and are hard to reproduce after an incident. A Helm chart or infrastructure template gives every environment the same definition. Ask whether your team can keep one versioned deployment definition and promote changes through environments before you add more copies of the Compose setup.

The team cannot patch a single host reliably

Compose puts host operating system updates, Docker updates, image pulls and authentik upgrades on the same people, and an upgrade mistake affects sign-in directly. Ask who on your team owns those steps, how often they can run them, and whether they can test a new authentik release before production. If that capacity is thin, a managed cloud or cluster service may move part of that work to the platform.

Multi-instance support needs an enterprise edition

Running several authentik instances for separate business units or regions may be covered by an enterprise tier rather than the open-source edition. The pricing page lists multi-instance deployment support under Enterprise Plus, so confirm whether your design needs it before committing to an architecture. Ask the vendor in writing what is included, and check the license terms for the enterprise directory, which carries its own license.

Questions teams ask before running authentik on Compose

What does running authentik on Compose cost, and what drives that cost?

Most of the cost is people time, not software. The authentik Community edition is free to use under the MIT license for most of the code, so your spend goes to the hosts, the PostgreSQL service, the reverse proxy and certificates, mail delivery, and the engineering time to build, test and document the setup. Hosting and database costs recur monthly. Setup labor is one-time, although upgrades and backups recur. Costs rise with the number of environments you need (test and production), the availability you require, how many people must be able to sign in, and how many applications need integration. Ask any partner for a written scope that lists each component, who provides it, and which items are one-time or recurring.

Can a small team run authentik on Docker Compose without outside help?

A small team with Linux, Docker, PostgreSQL and reverse proxy experience can usually run a single-host Compose setup, because the authentik Docker Compose guide positions Compose for test setups and small-scale production and calls for at least 2 CPU cores and 2 GB of RAM. The harder parts are rarely the containers. They are the secrets handling, the backup and restore testing, the upgrade procedure, the email path for recovery and codes, and the integrations with each application. If nobody on the team has run an identity provider before, plan for a reviewed build, not a first-attempt production launch. Confirm the skills in your team before deciding.

How long does a Compose deployment take?

The duration depends on scope and team experience, and this page does not give a figure. The main variables are the number of applications to connect, the number of identity sources, the external PostgreSQL and proxy setup, the testing you require, and whether your team has to learn authentik first. Ask any partner for a written scope with named milestones, the deliverables at each milestone, the client tasks that could delay them, and the acceptance tests that close the work. A fixed-scope agreement makes the timeline comparable across proposals.

What does the open-source edition include compared with the enterprise editions?

The pricing page lists three editions: Open Source (free, with community support through Discord), Enterprise at $5 per user per month billed annually plus $0.02 per external user per month, and Enterprise Plus starting at $20k annually. Enterprise-only features listed on that page include Google Workspace and Microsoft Entra ID integrations, mTLS client certificate authentication, privileged access management, password history, enhanced audit logging and ticket-based support for subscriptions over $1k. Enterprise Plus adds dedicated support with SLAs, multi-instance deployment support and FIPS compliance for FedRAMP requirements. Confirm current prices and the license text in the enterprise directory before you budget, because pricing pages change.

What does the work need from our organization?

Plan for four groups of client inputs before the build starts:

Hosts: one or more Linux servers or virtual machines with the required CPU and memory, plus backup storage and monitoring access.
DNS and certificates: the authentik hostname, any application hostnames behind the proxy, and certificates that your browsers and clients trust.
Identity owners: people who decide group structure, MFA policy, application access, and which users sign in through which source.
Application owners: contacts for each application to test sign-in, claims and logout, and a change window for cutover.

Also provide mail relay details for recovery and one-time codes, and an approver for secrets storage.

Which parts of the Compose setup cause the most trouble?

Most problems come from a few predictable areas. Mounting storage at the wrong path after an upgrade is one, since from authentik 2025.12 local files are served from /files and expect a mount at /data, so the older /media mount moves to /data/media. Secrets left in plain text in the .env file and shared widely is another. Reverse proxy headers that are not forwarded correctly, and email that never leaves the server, also cause failed logins and missing recovery messages. Finally, PostgreSQL connection limits matter after upgrading to 2025.10 or later, since authentik no longer uses Redis and the release notes warn of roughly 50% more PostgreSQL connections. Test each of these in a staging copy before production.

When is outside help worth paying for?

Outside help is usually worth considering when the setup must meet a formal assessment, when several applications and identity sources must be connected quickly, or when your team cannot cover upgrades, backups and on-call work. DeployOpen plans, implements, hardens, backs up, upgrades, documents and supports self-hosted open-source platforms inside your own infrastructure, usually under a fixed-scope agreement with written deliverables and timelines. Ongoing support is available as a retainer. DeployOpen does not issue audit reports or certifications, so independent auditors remain responsible for those decisions. If you need more than a single Compose host, the Kubernetes and AWS guides cover the next step.

Choosing between Compose and Kubernetes for authentik

Compose is the simpler choice for one host and a small team, and Kubernetes only pays off when you have the platform skills to run it. A Compose deployment of authentik is a server container, a worker container and PostgreSQL on one machine, which your team can inspect, restart and reason about with a few commands. Kubernetes adds scheduling, rolling upgrades and separate scaling for the server and worker, but it also adds a cluster to patch, ingress and storage to manage, and on-call duties that a single host does not create. Ask honestly whether anyone on your team already runs Kubernetes in production. If not, the platform cost usually outweighs the benefits for a small identity service.

The Kubernetes installation guide makes one point you should plan for before choosing either path: the PostgreSQL bundled with the Helm chart is meant for demonstration and test environments, and production should use a separately managed database. The same logic applies to Compose. The bundled database container is convenient on day one, but the database is where all authentik configuration and data lives, so the question is who backs it up, restores it and upgrades it. Decide that early, whether the database stays on the Compose host or moves to a managed service, because it shapes your backup and recovery design either way.

If you start on Compose, plan the move off the host as a project in its own right rather than a late-night change. The steps are the same as a Kubernetes move: an external PostgreSQL with tested restores, a shared place for uploaded files if more than one server needs them, and a documented upgrade order. Confirm the current requirements with the authentik Kubernetes installation guide and the Compose guide before you commit, since the answer to whether you need a shared file store depends on how many server instances you run.

What a fixed-scope Compose engagement covers

A fixed-scope engagement divides the work into parts that each end in a checkable deliverable. The scope, deliverables and timelines are agreed in writing before work starts, so the document defines what the partner builds, what the client provides and how acceptance is decided.

Host and network review

The first part checks the host against the Compose guide's baseline of at least 2 CPU cores and 2 GB of RAM, then sizes it for the user population and the applications that will depend on it. It also records inbound and outbound paths, DNS names, certificate authorities and which networks can reach the admin interface. The output is a short findings document the client signs off before any configuration changes.

Compose and secrets configuration

This part sets up the downloaded compose file, the server and worker services and the .env file that holds the secret key and database credentials. It defines who can read .env, how the file is backed up separately from the repository, and how image tags are pinned to a specific release. Acceptance requires that a restart of the stack keeps every secret and setting in place.

Storage and backup design

Here the team sets the /data mount for uploaded files, confirms the /data/media path for anyone migrating from a release before 2025.12, and schedules PostgreSQL dumps alongside the file volume. The deliverable is a written restore procedure with a named owner and a recorded restore test. Ask the partner to show the restore on a separate host, not only the backup job log.

Reverse proxy and TLS integration

This part places a reverse proxy in front of the server, sets forwarded headers, enables websocket paths and installs certificates from the client's chosen issuer. It confirms the proxy trusts only the intended upstream addresses and that the login flow works end to end over HTTPS. Plan for a short review of the proxy config, because a wrong forwarded-header setup often shows up first as broken redirects.

Acceptance testing

Acceptance testing runs against the criteria listed in the signed scope. Typical items include an administrator login with MFA, a test application sign-in through a provider, a failed-login lockout check, a forced restart and a restore from backup. Each test has an expected result and a recorded outcome, so the client can decide whether the work is complete without relying on the partner's word.

Handover documentation and upgrade notes

The final part delivers runbooks for routine tasks, a list of the versions in use, a note on the supported release lines and the security advisory process, and the criteria for moving to Kubernetes. It also records who receives the 24-hour advance notice of security releases. Confirm that the documentation is written for the client's own staff, since they will run the stack after the engagement ends.

How DeployOpen works on this

DeployOpen plans, implements, hardens, backs up, documents and supports self-hosted open-source platforms inside your own infrastructure. For authentik on Docker Compose, that means a written scope that fixes the host, the compose file, the secrets handling, the storage mounts and the backup routine before any server is touched. Engagements are fixed-scope, with the scope agreed in writing first.

How we scope

Confirm the host count, CPU and memory, operating system and the Docker Engine version you will run on.
Agree which authentik release line you will deploy and how upgrades will be staged over time.
Record which providers, applications and user populations the first deployment must serve.

How we build

Pull the Compose file from the documented source, pin image versions and set the .env secrets outside version control.
Place storage under the /data mount that current releases expect, and migrate any legacy /media path.
Test login, MFA, a restore from backup and a forced restart before the instance is accepted.

How we hand over

Deliver a runbook covering start, stop, upgrade steps, secret rotation and the backup and restore procedure.
Document the criteria your team should use to decide when a move to Kubernetes is warranted.
Walk your operators through the monitoring and log locations so day-two work stays with your team.

How we support

Offer ongoing support, upgrades and continuous testing as a retainer after handover, scoped in writing.
Review each new authentik security release against your deployment and schedule the change window.
Re-run backup restore tests on a planned cadence agreed in the retainer scope.