authentik Docker Compose vs Kubernetes: Which to run

Docker Compose or Kubernetes for authentik: when each model fits

A team deciding where to run authentik usually has one question: does the platform already exist to run it? Docker Compose fits test setups and small-scale production on a single host, while the Helm chart on Kubernetes fits teams that already run a cluster and have people to operate it. The authentik Docker Compose guide asks for a host with at least 2 CPU cores and 2 GB of RAM and positions the method for test setups and small-scale production. If your identity service must survive a single host failure, or your organization expects to scale it through a platform team, Compose is the wrong starting point, and the Kubernetes path deserves the extra effort.

Both models run the same core components: a server (core plus an embedded outpost for proxy providers), a worker for background jobs such as email and event notifications, and PostgreSQL, which holds all configuration and data except uploaded files. The choice therefore changes how you operate authentik, not what it can do. Features, protocols and the Enterprise edition decisions are the same under either model. Before you pick, confirm which volumes your deployment needs, since the server writes uploaded icons and flow backgrounds to /data and the worker reads imported certificates from /certs, and the Helm chart does not mount storage for uploads by default.

The most important Kubernetes detail is the database. The authentik Kubernetes guide says the PostgreSQL installed by default with the chart is intended for demonstration and test environments. For production, the authentik docs recommend a separately managed PostgreSQL installation and name CloudNativePG and the Zalando Postgres Operator as common options. Budget for that database as a platform service with its own backups, upgrades and failover, and ask whoever operates your clusters how they will run it. Confirm current chart behavior, including autoscaling of server and worker replicas, in the authentik Kubernetes installation docs before you commit to a design.

How the two deployment models compare on the factors that matter

This table compares the official Docker Compose file and the authentik Helm chart on documented suitability, components, database ownership, storage, ingress, scaling, upgrades and skills. Read each row as a documented behavior to verify in your own environment, then weigh it against your team's operating model and growth plans.

Factor	Docker Compose on one host	Helm chart on Kubernetes
Documented suitability	Test setups and small-scale production, per the authentik Docker Compose guide	Production use is supported, but the docs say the bundled PostgreSQL is for demonstration and test only
Components run	Server with embedded outpost, worker and PostgreSQL on one host	Server, worker and PostgreSQL as pods, with PostgreSQL normally managed separately for production
Database responsibility	You run and back up the PostgreSQL container on the host	For production, you use a separately managed PostgreSQL such as CloudNativePG or the Zalando Postgres Operator
Storage for /data and /certs	Host volumes must be defined for uploaded files and imported certificates, or external media URLs used	The chart does not mount storage for uploaded files by default, so you must add persistent volumes or use external media URLs
Ingress	Reverse proxy or port mapping configured on the host	The chart creates an HTTPRoute but not the Gateway or GatewayClass, so you must provide those resources
Scaling	Single host; scaling means a larger host, not more replicas	Server and worker replicas can be scaled automatically per the authentik autoscaling guide, subject to your database capacity
Upgrade path	Pull new images and restart the stack; back up PostgreSQL first	Upgrade the chart and image tags through Helm; you also manage the database and cluster upgrade cycle
Skills needed	Docker, Linux administration, PostgreSQL backups and reverse proxy setup	Kubernetes operations, Helm, persistent storage, Gateway API, and a PostgreSQL operator or managed service

What runs in each model: server, worker and PostgreSQL

Whether you run authentik on one Compose host or on Kubernetes, the same three components do the work: a server, a worker and PostgreSQL. The cards below describe each one and the storage and connection checks that matter for either model.

The server container

The server runs the authentik core and an embedded outpost, which handles proxy providers. Users, applications and login flows all pass through it, so it is the component that sets your response times and your exposure to the network. In Compose it is one service behind your reverse proxy. On Kubernetes it is a Deployment that the Helm chart creates and that you can scale. Check that the outpost reaches every protected application from the network path it will use in production.

The worker container

The worker runs background jobs such as sending email and processing event notifications. If it stops, logins can still succeed while notifications and scheduled work quietly pile up, so a healthy server does not prove the platform is healthy. In Compose, confirm the worker container is running after each update. On Kubernetes, scale server and worker replicas separately and check that email delivery works from the worker's network location.

PostgreSQL as the data store

PostgreSQL holds all configuration and data except uploaded files, so it is the component you must back up and restore before anything else. Compose can run a PostgreSQL container alongside authentik, but the chart's bundled database is intended for demonstration and test use. For production on Kubernetes, plan a separately managed PostgreSQL with its own backup, restore testing and upgrade process. Ask who owns that database and who is paged when it fails.

No Redis since 2025.10

authentik no longer uses Redis. Since the 2025.10 release, caching, background tasks, sessions and WebSocket functions run on PostgreSQL. This removes one service from both models, but it moves that load onto the database. Include session and cache traffic when you size the database and when you plan its backups and failover.

Connection count after upgrading

The 2025.10 release notes warn of roughly 50% more PostgreSQL connections after upgrading. Teams that moved from an older release with Redis may see the connection ceiling reached sooner than expected. Before upgrading, check the maximum connection setting on your database and the number of server and worker replicas, since each one holds connections. Ask your database operator whether a connection pooler belongs in the design.

Why the chart's bundled database is not for production

The authentik Helm chart installs a PostgreSQL database by default, and the authentik Kubernetes guide says that database is intended for demonstration and test environments. Treat it as a way to get a cluster running quickly, not as the place where your identity configuration and user data live. For production, the authentik docs recommend a separately managed PostgreSQL installation, and they name CloudNativePG and the Zalando Postgres Operator as common options. Decide which operator or managed service your platform team already supports before you install the chart, because the database owns backups, failover, minor version patching and storage sizing, and each of those becomes your responsibility.

Uploaded files need a separate decision. The chart does not mount storage for uploaded files by default, and the server writes icons and flow backgrounds to /data. Compose has the same requirement, so the storage question is not a reason to pick one method over the other. Either add a persistent volume for /data that survives pod rescheduling, or host those assets at external media URLs. Also check that imported certificates read by the worker from /certs are mounted where both pods can reach them when you scale replicas.

Before you go live, ask the vendor or your database operator to confirm how the external database is backed up and restored for authentik's schema, how point-in-time recovery is tested, and who runs a restore drill. Confirm that a restore brings back users, applications, flows and keys together, and that a restored database works with the chart's current release. Ask for these answers in writing as part of the implementation scope, since authentik's documentation does not describe a backup procedure for your cluster.

Which model fits which team situation

The authentik Docker Compose installation guide calls for a host with at least 2 CPU cores and 2 GB of RAM and positions this method for test setups and small-scale production. For a team with one or two administrators and no existing cluster, that is the documented fit. The deployment is a server container, a worker container and PostgreSQL, all managed through one Compose file on one host.

Host ownership: The team patches the operating system, Docker engine and host firewall itself.
Database backups: The team schedules and tests PostgreSQL backups and restores, since the database holds all configuration and data except uploaded files.
Volumes: The team mounts the volumes for uploaded files such as icons and flow backgrounds, and for imported certificates, or uses external media URLs.
Upgrades: The team reads release notes for each authentik version before pulling new images, including database connection changes.
Recovery: A single host is a single point of failure, so the team must define how long a rebuild can take and who performs it.

Before committing, confirm with your own change calendar and staffing whether one host and one administrator can cover these duties.

Upgrades, backups, monitoring and skills for each model

This table compares what each deployment model asks of your team after go-live: upgrades, backups, monitoring and skills. Read it as a checklist of operating work, then match each row to the people you actually have. The main takeaway is that Compose concentrates the work on one host and one database, while Kubernetes adds cluster-level duties that need their own owners.

Area	Docker Compose on one host	Helm chart on Kubernetes
Upgrade path	Pull the new authentik image, review release notes, then restart the server and worker containers on the host. You control the timing of each release.	Upgrade the chart and image through your GitOps or Helm process, after first upgrading the cluster itself. Kubernetes must move one minor version at a time, with kube-apiserver first.
Security patch timing	authentik's security policy lists 2026.5.x and 2026.8.x as supported lines. Security releases are announced at least 24 hours in advance, so plan a window to apply them.	Same authentik security policy applies. Schedule the 24-hour notice into your change process so that the cluster and chart upgrades do not collide with a security release.
Kubernetes version lifecycle	Not applicable to the host model, but the host OS and Docker Engine still need their own patch schedule.	Kubernetes maintains the three most recent minor releases. Plan cluster upgrades before your running minor version leaves support, and check kubelet skew against kube-apiserver before each step.
Backups	Your team backs up the PostgreSQL database and the data volumes for uploaded files such as icons. Test restores on a second host.	Your team owns PostgreSQL backups through its managed database service or operator, plus the storage for /data and /certs. Cluster state, including etcd snapshots, is a separate backup duty if you run the control plane.
Control plane and etcd	No control plane to run. Host backups and the Docker host rebuild procedure are the main recovery steps.	Self-managed clusters need etcd backups with etcdctl snapshot save, restore procedures with etcdutl, and an odd-numbered etcd membership, with five members recommended in production. The kubeadm HA guide describes a stacked topology with at least three control plane nodes behind a TCP load balancer on port 6443.
Monitoring	Host metrics, container health, PostgreSQL connections and disk use. After the 2025.10 release, expect higher PostgreSQL connection counts than before, so watch connection limits.	Pod health, autoscaling events, PostgreSQL connections and storage claims, plus node and control plane health. Alerts need to cover the cluster as well as the application.
Skills your team needs	Linux administration, Docker and Compose, PostgreSQL operations, reverse proxy and TLS management.	Kubernetes administration, Helm, RBAC, storage classes, PostgreSQL on Kubernetes, and cluster upgrade and etcd recovery procedures. Confirm that at least two people can run these tasks.
Who to ask in a quote	Ask the implementer to specify backup scope, restore testing, upgrade runbook and monitoring thresholds in the written scope.	Ask for cluster upgrade and etcd procedures to be in scope or explicitly excluded, plus the owner of PostgreSQL operations and the 24-hour security notice process.

What running a Kubernetes cluster adds to the bill

Moving authentik from one Compose host to the Helm chart means paying for a cluster that exists only to run it. The cluster's control plane, its etcd members and a TCP load balancer in front of kube-apiserver on port 6443 all need to be designed, built and kept running. The kubeadm high availability guide describes a stacked topology, with etcd on the control plane nodes, and an external etcd topology, and it calls for at least three control plane nodes. Before you accept any quote, confirm which topology the consultant proposes, who provisions the load balancer, and whether the cluster already exists or is part of the same scope. Design and installation are one-time costs. Running etcd and the control plane is a recurring cost.

The PostgreSQL database is the second line item. The authentik Kubernetes guide says the database the chart installs by default is for demonstration and test environments, so production needs a separately managed PostgreSQL, such as CloudNativePG or the Zalando Postgres Operator. That operator, or a managed database service, has its own install, backup, restore and upgrade work. Ask the consultant who owns backups and restore testing for PostgreSQL, how point-in-time recovery is handled, and whether that work is in the fixed scope or a retainer. Storage is a third item: the chart does not mount storage for uploaded files by default, so the storage class, volume sizing and backup policy for /data must be agreed in writing.

The largest recurring cost is upkeep. Kubernetes ships about three minor releases a year on a cycle of roughly 14 weeks, and the project supports only the three most recent minor versions. The version skew policy requires kube-apiserver to be upgraded one minor version at a time, before the other control plane components and the kubelets. Each upgrade also has to be checked against the authentik chart version. Ask for the upgrade cadence the consultant will commit to, how staging clusters are used to rehearse upgrades, who is on call for failed rollouts, and how etcd snapshots taken with etcdctl snapshot save are restored and tested. Quotes should separate the one-time build from the retainer that covers patching, upgrades, on-call and backup verification, and should name who pays the cloud or data center bill for the nodes.

Questions buyers ask before choosing Compose or Kubernetes

Is Docker Compose acceptable for running authentik in production?

Yes, for some teams. The authentik Docker Compose guide positions this method for test setups and small-scale production, with a host of at least 2 CPU cores and 2 GB of RAM. Compose runs the server, the worker and PostgreSQL on one host, so a host failure takes all three down together. That fits a single site with a modest user base and a small platform team that can accept a short outage during recovery. Confirm your availability target, your restore time objective, whether one host satisfies your change control process, and how far your login service must keep working during host maintenance.

Why is the authentik Helm chart database not meant for production?

The chart installs a PostgreSQL database by default, and the authentik Kubernetes guide says that database is intended for demonstration and test environments. For production, authentik recommends a separately managed PostgreSQL installation and names CloudNativePG and the Zalando Postgres Operator as common options. This matters because authentik stores all configuration and data except uploaded files in PostgreSQL, so the database holds the state you must back up and restore. Your team then owns backups, failover, version upgrades and monitoring for that database. Ask which operator you will use, where backups land, and who runs and records restore tests.

Do we need Kubernetes to autoscale authentik?

Autoscaling is the reason to choose the Helm chart, because the authentik Kubernetes installation documentation says server and worker replicas can be scaled automatically by following its autoscaling guide. Docker Compose does not offer an equivalent in the supplied material, so scaling a Compose host means manual changes to the host or a larger host. Autoscaling only helps when the constraint is stateless server or worker capacity. Database capacity is a separate limit: the authentik 2025.10 release notes warned of roughly 50% more PostgreSQL connections after upgrading, which means your database sizing and connection limits need review before you add replicas. Confirm your peak login volume and whether it justifies a cluster.

How much effort does each deployment model take to run?

Compose effort concentrates on one host: operating system patching, container runtime updates, backups, authentik upgrades and the PostgreSQL layer. Kubernetes adds the cluster itself. The kubeadm high availability guide describes at least three control plane nodes with a TCP load balancer in front of kube-apiserver on port 6443, and the etcd guidance calls for an odd member count, a five-member cluster in production and a tested backup plan. Kubernetes also ships roughly three minor releases a year on a cycle of about 14 weeks, so cluster upgrades recur on top of authentik upgrades. If you already run a supported cluster, the marginal effort is smaller. Ask for quotes that separate cluster work from authentik work.

What does running authentik need from our internal team?

Compose requires people who can manage Linux hosts, Docker Compose, TLS certificates for the login domain and PostgreSQL backups. Kubernetes adds cluster administration, RBAC design, storage class decisions and Helm release management. Both models need a named owner for identity configuration, including providers, flows and application onboarding. Both also need persistent volumes for uploaded files: the server stores icons and flow backgrounds in /data and the worker reads imported certificates from /certs, and the chart does not mount storage for uploads by default. On Kubernetes, Secrets are stored unencrypted in etcd by default, so encryption at rest is a decision your team must make and document. Confirm who holds on-call responsibility for a login outage.

Can DeployOpen run authentik on either model in our environment?

DeployOpen plans, implements, hardens, backs up, upgrades, documents and supports self-hosted open-source platforms inside the client's own infrastructure, including cloud accounts, data centers and air-gapped networks. Most engagements are fixed-scope, so scope, deliverables and timelines are agreed in writing before work starts, and ongoing support, upgrades and testing are available as retainers. DeployOpen does not publish a price list, so a quote follows from the written scope. Before you ask for one, confirm which platform your team already operates, how PostgreSQL will be run, where backups are stored, which secrets approach you require, and what your internal team will own after handover. DeployOpen prepares controls and evidence for compliance assessments but does not issue audit reports or certifications.

Which model is easier to defend in a compliance assessment?

Neither model is compliant on its own, and the choice matters less than the evidence you can produce. Compose gives a smaller system boundary: one host, one database and fewer components to document. Kubernetes gives more controls to configure, including encryption at rest for Secrets, least-privilege RBAC for list and watch access, and Pod Security Standards, but each one needs an owner and evidence. The CIS Kubernetes Benchmark is a relevant reference for cluster hardening, and an independent assessor decides whether your controls meet a given framework. Ask your assessor which boundary they expect, and ask DeployOpen to document controls and evidence for that boundary, recognizing that DeployOpen does not issue attestations.

Does the Enterprise edition change the deployment choice?

The deployment model does not change the license. Code under authentik/enterprise is licensed under the authentik Enterprise Edition license and needs a paid subscription for production use, whether the server and worker run under Docker Compose on one host or under the Helm chart on Kubernetes. The core remains MIT licensed in both cases, so the choice between Compose and Kubernetes is a question of operations, not of licensing. Confirm the terms with the vendor and read the authentik LICENSE file before you assume any enterprise module is covered by the free edition.

The pricing page lists Enterprise at $5 per user per month billed annually, plus $0.02 per external user per month. Enterprise Plus starts at $20k annually and adds dedicated support with SLAs, multi-instance deployment support and FIPS compliance for FedRAMP requirements. Price follows user count and edition, not the number of hosts, so a Compose deployment and a Kubernetes deployment of the same user base carry the same subscription. Ask the vendor to confirm how external users are counted and whether multi-instance support is included in the edition you need.

Multi-instance support and SLA commitments matter mainly if you plan a second authentik instance, for example for a disaster recovery site or a separate production and staging pair. A single Compose host is a single point of failure for the server, worker and PostgreSQL, so a team that needs an SLA will have to plan redundancy around the host, not only around the software. Write these requirements into the scope before choosing the deployment model, and ask for the support terms in writing before the subscription starts.

How DeployOpen scopes and runs authentik deployments

DeployOpen plans, implements, hardens, backs up, documents and supports self-hosted open-source platforms inside the client's own infrastructure, so the Compose or Kubernetes decision is made against your environment rather than a generic template. Most engagements are fixed-scope, with scope, deliverables and timelines agreed in writing before work starts.

How we scope

We confirm which deployment model fits your hosts, cluster, network and team before any build work starts.
The written scope names the PostgreSQL option, the storage for uploaded files and the backup approach.
We list the identity integrations, protocols and any Enterprise features you need, so licensing is settled up front.

How we build

We install the server and worker with PostgreSQL in your environment, using either the Compose file or the Helm chart.
Persistent volumes for uploaded files and imported certificates are configured and tested in the agreed model.
We test sign-in, provider configuration and failover behavior against the scope before handover.

How we hand over

You receive documentation of the chosen topology, configuration, secrets handling and upgrade steps.
Backup and restore procedures for PostgreSQL are documented and exercised before handover.
Runbooks describe how to upgrade authentik and the surrounding platform in your own change process.

How we support

Ongoing support, upgrades and continuous testing are available as retainers after handover.
Retainers can cover version upgrades, patching and periodic review of the deployment against the written scope.
Compliance evidence for your assessments is prepared by us, while independent auditors issue any audit reports.

authentik Docker Compose vs Kubernetes