authentik on Kubernetes with Helm for production

Authentik on Kubernetes with Helm: when the chart fits production

The Helm chart fits production when your platform team already runs Kubernetes and will own a separately managed PostgreSQL database for authentik. The official Kubernetes install uses Helm, and the guide in the authentik Kubernetes installation documentation is the starting point for that path. The chart's bundled PostgreSQL is meant for demonstration and test environments, and the project recommends a separately managed PostgreSQL for production. Treat the bundled database as a way to evaluate the install, not as a production data store, and plan the external database before you write the values file.

A running authentik deployment has three parts. The server container runs the core application with an embedded outpost, the worker container runs background tasks, and PostgreSQL stores all configuration and data except uploaded files. Because the server and worker are separate workloads, you can scale and restart them independently, but both must reach the same database. Since the 2025.10 release, authentik no longer uses Redis and moves caching, tasks, sessions and WebSocket functions into PostgreSQL, so database connection planning is part of the Kubernetes design, not an afterthought.

Confirm the licensing position with your legal and procurement teams before you standardize on the chart. Most of authentik's code is under the MIT license, but code in the authentik/enterprise/ directory falls under a separate enterprise license defined in that directory. Enterprise features such as the Microsoft Entra ID and Google Workspace integrations are priced on the pricing page, so check which features your SSO design depends on. The authentik LICENSE file on GitHub is the place to confirm the exact terms that apply to your version.

Which values and deployment choices fit each environment

A test cluster fits the chart's bundled PostgreSQL, which the authentik Kubernetes guide describes as intended for demonstration and test environments. Use this model to learn the chart, rehearse upgrades or check blueprints before they reach production. Keep the bundled database enabled in values.yaml, accept its defaults, and focus on confirming that the server and worker pods start, that ingress routes correctly and that a test login completes.

Database lifecycle: The bundled database is part of the Helm release, so the team owns its storage class, its backups and any data loss that follows an uninstall.
Secrets: Generated secrets are acceptable for a test release, but record where they are stored and rotate them before any real directory or application is connected.
Replica counts: Run one server and one worker to keep the footprint small and the troubleshooting path short.
Ingress: Use a test hostname and a certificate from a non-production issuer.

Before you copy this values file into production, check that test-only settings, including the bundled database toggle, are removed or replaced.

Installing authentik on Kubernetes with Helm in order

This sequence takes a cluster from version check to a verified authentik login with external PostgreSQL, managed secrets, ingress, autoscaling and a written upgrade runbook. Each step closes with a check so the team knows it can move on.

Confirm cluster version and support window
The platform team checks the Kubernetes minor version of the target cluster against the supported releases listed on the Kubernetes releases page, and confirms that the cluster's upgrade cadence fits the team's change calendar. Kubernetes maintains the three most recent minor releases, so a cluster on an older line needs an upgrade plan before authentik goes in. Confirm the authentik version you intend to install against the authentik security policy, which lists the supported release lines. Check that the cluster has an ingress controller, a storage class and a working DNS name for the login endpoint. Done means a written record of the cluster version, the authentik version and the support dates for both.
Provision external PostgreSQL and credentials
Your database team provisions a PostgreSQL instance outside the chart, either as a managed service or as an operator-run cluster such as CloudNativePG, which is an Apache-2.0 operator for PostgreSQL on Kubernetes. The authentik Kubernetes guide states that the bundled PostgreSQL is for demonstration and test use and recommends a separately managed database for production. Create a dedicated database and role for authentik, enable TLS, and confirm backup and point-in-time recovery settings with the owner of the database service. Confirm the connection limits with the authentik documentation for your version, since authentik moved caching and tasks into PostgreSQL. Done means you can connect to the database from a test pod in the authentik namespace with the new role.
Generate secrets outside the chart and store them
Generate the secret key and database password outside the Helm release, using a tool your team controls, and write them to a secrets store such as OpenBao, a cloud key vault or an external secrets operator backed by one of those. Kubernetes stores Secrets unencrypted in etcd by default, so confirm that encryption at rest is enabled on the cluster and that RBAC limits list and watch access to the namespace. Reference the stored values from the chart rather than typing them into a values file committed to source control. Record who can rotate each secret and how a rotation reaches the running pods. Done means the authentik namespace contains Kubernetes Secrets synced from the store, and a search of your values files and Git history finds no plaintext credentials.
Set minimum Helm values for server and worker
Your platform engineer writes a values file that points the chart at the external PostgreSQL host, database name, user and TLS settings, and references the secrets from the previous step. Set the server and worker sections explicitly so each has its own replica count and resource requests, and confirm the image tag matches the version chosen in step one. Disable the bundled PostgreSQL subchart so the chart does not deploy a demonstration database. Run helm lint and helm template against the values file and review the rendered manifests for the Secret references and the database host. Done means the rendered output contains a server Deployment and a worker Deployment that both read the external database settings, with no bundled database resources.
Configure ingress and TLS for the login endpoint
Create the ingress resource through the chart values, using the ingress class your controller provides and the public hostname for authentik. Attach a certificate from your certificate manager or a corporate certificate authority, and confirm that the proxy headers and websocket handling your ingress controller uses match the authentik reverse proxy guidance for the version you run. Decide whether authentik trusts forwarded addresses only from your ingress controller's CIDR range, because that setting affects client IP handling and audit records. Done means the hostname resolves, the certificate chain validates from a client outside the cluster, and an HTTP request to the root path reaches the authentik server pod through the ingress.
Install the chart and verify health and login
Install or upgrade the Helm release into the authentik namespace with the reviewed values file and a pinned chart version, then wait for the server and worker rollouts to finish. Check the readiness and liveness endpoints for the server pods, review worker logs for database migration completion, and confirm that the worker reports healthy background tasks. Retrieve the initial administrator setup through the mechanism documented for your version, complete the first login over the public hostname, and create a test user to sign in to a test application. Done means both Deployments are available, migrations completed without errors, and a test sign-in succeeds through the ingress with the database showing new session and user rows.
Set autoscaling for server and worker
Enable horizontal autoscaling for the server and worker Deployments through the chart values or separate HorizontalPodAutoscaler objects, using CPU or memory targets your load tests support. Set minimum and maximum replica counts after measuring login volume and background task load on a non-production copy, and confirm that the cluster has a metrics pipeline the autoscaler can read. Account for the connection count each replica opens against the external database, because more replicas mean more connections, and size the database or pooler to match. Done means a load test raises the replica count within the configured bounds, and the database connection count stays within the limit your database team set.
Document the upgrade runbook
Write a runbook that covers the pre-upgrade backup of the external database, the release notes review for the target authentik version, the sequential version path the project requires, and the chart value changes that accompany each release. Include the Kubernetes version skew check from the Kubernetes version skew policy, the change window, the rollback path through the previous Helm revision, and a post-upgrade login test. Assign an owner for each step and store the runbook beside the values file under version control. Done means a dry run in a non-production cluster completes against the runbook, and the team signs off on the document before the first production upgrade.

Scaling authentik servers and workers without overloading PostgreSQL

Server and worker replicas both draw on the same PostgreSQL instance, so scaling one tier changes the load on the other. The cards below cover the decisions that connect replica counts, autoscaling, connection limits and the session and cache work that now lands in the database.

Server replica count

The server container runs core and an embedded outpost, and it handles login traffic, API calls and WebSocket connections. Start with a replica count that matches your expected concurrent sign-ins, then add replicas only after you have measured request latency. Each added replica opens its own pool of database connections, so the replica count directly sets part of your connection budget. Confirm the server replica key and its default in the official Kubernetes guide before you set it.

Worker replicas for background tasks

The worker container runs background tasks such as scheduled jobs, blueprint application, email sending and outpost-related housekeeping. Workers are not in the login path, so their replica count should follow task backlog rather than user volume. Scaling workers up without checking the database can move the bottleneck from task processing to PostgreSQL. Confirm the worker replica key in the chart values and check whether your version runs workers as a separate deployment.

Autoscaling triggers and limits

Horizontal autoscaling on CPU or memory works for the server tier, but it can add replicas faster than the database can accept connections. Set a maximum replica count that your PostgreSQL connection limit can support with headroom for administrators and maintenance jobs. Use a separate, conservative ceiling for workers. Confirm the autoscaling key names, the target metrics and the minimum and maximum fields against the official chart guide, since they are chart-specific.

PostgreSQL connection limits and pooling

Since the 2025.10 release, authentik no longer uses Redis, and the release notes warn of roughly 50% more PostgreSQL connections after upgrading. Calculate the total connections as replicas multiplied by the pool size per pod, plus workers and administrative sessions. Check the connection ceiling of your managed or self-run PostgreSQL before you raise any replica count. If you place a pooler in front of the database, confirm which pooling modes authentik supports in your version.

Session and cache load on PostgreSQL

Caching, tasks, sessions and WebSocket functions now run in PostgreSQL, so write load and row churn grow with active users and background activity. Watch database CPU, I/O, lock waits and table bloat during login peaks, not only the connection count. Plan vacuum and retention for session and task data, and test a sign-in burst against a staging copy of your database before production rollout.

Load testing before changing replicas

Scaling decisions should rest on measurements from your own environment rather than on general sizing guidance. Run a sign-in and token-issuance test that matches your peak login rate, record server latency, worker queue depth and PostgreSQL connection usage, then change one variable at a time. Keep the results with your change record so the next upgrade can be compared against a known baseline.

Generated secrets and external PostgreSQL in the cluster

Keep authentik's secrets out of plain values files and in a managed store. The secret key, bootstrap credentials and database password should be generated or pulled from a store at install time, not typed into a values.yaml that gets committed to Git. Kubernetes Secrets are stored unencrypted in etcd by default, so anyone who can read etcd backups or list Secrets through the API can read them. Before you go live, confirm that encryption at rest is enabled for Secrets in your cluster, restrict get, list and watch on Secrets with least-privilege RBAC for the namespace where authentik runs, and decide whether an external store, reached through the Secrets Store CSI Driver, will hold the values instead. Check the authentik Helm chart's documentation for which keys it reads from an existing Secret, so you can point it at the managed copy.

Moving PostgreSQL out of the chart changes the trust boundary. The chart's bundled database is for demonstration and test use, so production needs a database you run or buy separately, with its own TLS, credentials, network policy and backup chain. Once the database is outside the release, you own certificate verification between authentik and PostgreSQL, the rotation of its credentials, and the restore procedure, and an authentik outage can follow a database fault that the chart never surfaced. One operator option to evaluate is CloudNativePG, an Apache-2.0 operator for PostgreSQL on Kubernetes that handles automated failover through the Kubernetes API, synchronous replication, and backups to object storage with point-in-time recovery. Confirm the instance count, storage class, PostgreSQL major version, backup target and restore test cadence with the operator and your own recovery targets, since these depend on your data volume and availability needs.

Security and operational risks of the Kubernetes deployment

A Helm-based authentik install inherits the security posture of the cluster around it. The cards below cover the places where that posture most often breaks: admin reachability, namespace policy, secret access, etcd protection, image sourcing and log retention. Check each one against your own cluster before the first production login.

Exposed admin endpoints through ingress

The authentik admin interface and its API are served on the same host as user sign-in unless you decide otherwise. Route the admin paths through an ingress rule that only your administrative network or VPN can reach, and confirm that the ingress controller does not expose them on a public hostname. Test the restriction from outside your network, not only from inside the cluster.

Pod Security Standards for the namespace

Apply a Pod Security Standards level to the namespace that runs authentik and its workers, and check that the chart's pod settings satisfy it. Run the check in audit or warn mode first so you can see which pods would be rejected. Record any exception you grant, along with the reason and an owner.

RBAC on secrets

Kubernetes Secrets hold the authentik secret key and database credentials, and they are stored unencrypted in etcd by default. Limit get, list and watch on Secrets to the service accounts and administrators who need them, because list and watch can expose every value in a namespace. Review who can read the namespace after each chart upgrade.

etcd encryption and backups

Configure encryption at rest for Secret resources in the API server, and confirm that your distribution has done so. Back up etcd on a schedule, store the snapshots outside the cluster, and rehearse a restore. Authentik's own database holds its configuration and user data, so an etcd backup alone does not protect it.

Image provenance and mirroring

Pin the authentik server and worker images to a specific release tag or digest rather than a floating tag, and pull them from a registry you control. Mirror the images into that registry and scan them before promotion. Confirm the supported release line in the security policy before choosing the tag you pin.

Log forwarding and retention

Authentik writes login, flow and administrative events to container logs, and cluster logs are lost when pods are rescheduled. Forward logs from the server and worker pods to a central store with a retention period set by your security policy. Confirm which events your audit requirements need and test that they arrive.

Upgrading authentik on Kubernetes without breaking logins

Plan every authentik upgrade around the release naming. Versions are named by year and month, so 2026.8.4, published on October 14, 2026 according to the authentik releases on GitHub page, belongs to the 2026.8 line. The authentik security policy lists 2026.5.x and 2026.8.x as the lines receiving security fixes, so a deployment on any other line should be scheduled for a move onto a supported one. The project announces security releases at least 24 hours in advance, which is shorter than many change windows. Subscribe to the release feed and keep a standing rule that a security release is staged in a non-production namespace the same day it is announced.

Before you change any image tag in the Helm values, read the release notes for every version between your current one and the target, and confirm the sequential upgrade rule for that path. Your team, not the chart, owns the breaking-change review, so record which settings, provider behavior or database requirements changed in each release and who signed off. Server and worker containers should move to the same authentik version in one change, and the database migrations run as part of that rollout, so take a verified PostgreSQL backup first. Keep the previous image tags and Helm revision so a failed rollout can be reversed with helm rollback.

Treat the Kubernetes cluster as a separate upgrade with its own checks. The Kubernetes version skew policy requires kube-apiserver to be upgraded one minor version at a time, before the controller manager, scheduler and kubelets, and allows kubelets to lag by up to three minor versions. Confirm the cluster version is still inside the project's support window on the Kubernetes releases page, since an unsupported control plane will block the work regardless of authentik. Check the PostgreSQL operator and database version too, because authentik's requirements and your chosen operator may move on different schedules.

Questions buyers ask before installing authentik on Kubernetes

Can our team install authentik on Kubernetes without outside help?

Yes, many platform teams can, provided they already run Kubernetes, Helm and a managed PostgreSQL service and have an owner for identity decisions. The Helm install itself is a documented path. The harder parts are the decisions around it: an external PostgreSQL instead of the chart's bundled demo database, ingress and TLS, how secrets are generated and stored, and how server and worker replicas are scaled. Ask your team to name who will own each of those before deciding between an internal build and a partner. Your own platform maturity matters more than the installer.

What does the work need from our side?

A partner or internal team will need access to a non-production cluster, a PostgreSQL instance you can provision or approve, DNS names and certificates for the authentik hostname, and a secrets store or policy for generated keys. You also need named contacts for identity decisions, such as which applications sign in first and which groups map to access. Security and change approval staff should review the values file and the upgrade plan before anything reaches production.

What drives the cost of installing authentik on Kubernetes?

Cost follows the number of components you must build and operate, not the Helm command. The main drivers are the external PostgreSQL setup and its backups, ingress and certificate integration, the secrets approach, how many applications and providers you onboard, and how many upgrade cycles you plan for in the first year. One-time costs include design, build and cutover. Recurring costs include the platform team's time for upgrades, monitoring and database operations. Ask every quote to separate those lines.

Is a fixed-scope quote available for this installation?

Yes. DeployOpen's engagements are generally fixed-scope, with scope, deliverables and timelines agreed in writing before work starts. A written scope for this topic would normally list the target clusters, the PostgreSQL option, ingress and certificates, the number of applications in the first release, verification steps and the handover. DeployOpen does not publish a price list, so a quote follows from that written scope. Ongoing upgrades and support can be handled under a retainer.

How long does a rollout take?

The duration depends mainly on how mature your platform already is. A team with a working cluster, a managed PostgreSQL service, certificate automation and a tested GitOps or Helm workflow will move faster than one that must first build those pieces. Other factors include the number of applications to connect, approval cycles for production changes and the extent of testing. No fixed duration applies to every environment, so ask for a timeline in the written scope after a short review of your current platform.

Which upgrade effort should we plan for?

Plan for authentik upgrades as a repeatable process with a rollback path. authentik publishes its supported versions in its security policy, and security releases are announced at least 24 hours in advance, so your change window needs to accommodate short notice. On Kubernetes, server and worker images are upgraded together, and database changes must be tested against a copy of production data. Also confirm how the Kubernetes version your cluster runs fits its own support window, since Kubernetes minor releases reach end of life on a fixed schedule.

What do Enterprise features change, and do we need them?

The enterprise license applies only to code in the authentik/enterprise/ directory. Most of the repository is under the MIT license. The pricing page lists Enterprise features such as Google Workspace and Microsoft Entra ID integrations, mTLS client certificate authentication, privileged access management, password history and enhanced audit logging. Enterprise pricing is listed there: $5 per user per month billed annually plus $0.02 per external user per month, with Enterprise Plus starting at $20k annually. Check which features your requirements need before choosing an edition, and confirm current terms with authentik.

Limits to confirm in your environment before go-live

The authentik Helm chart, the authentik release, the Kubernetes cluster, PostgreSQL and the ingress layer each carry their own version and capacity limits. Confirm them together before go-live, because a valid combination on one component can be unsupported on another.

Chart and authentik versions

Pin the Helm chart version and the authentik image tag together, then read the release notes for every version between your target and the current one. authentik names releases by year and month, and the project supports only specific release lines for security fixes. Confirm with the vendor which lines receive security updates on the day you go live, and plan your upgrade cadence around that window.

Supported Kubernetes versions

Check that your cluster's minor version is still maintained by the Kubernetes project and that your distribution is certified for the APIs the chart uses. Kubernetes support windows are short, so a cluster that is current on the day you install may need an upgrade within months. Ask your distribution vendor which Kubernetes version your managed control plane will run and when it changes.

PostgreSQL version and connection budget

Confirm the PostgreSQL major version your external database runs and whether your operator or managed service supports it. authentik no longer uses Redis, so caching, tasks and sessions all draw on PostgreSQL connections, and the 2025.10 release notes warned of roughly 50% more connections after upgrading. Count server and worker replicas multiplied by connections per pod, then compare the total with your database limit and any pooler in front of it.

Ingress controller and TLS model

Decide which ingress controller terminates TLS, whether the certificate comes from cert-manager, a cloud load balancer or a corporate CA, and how forwarded headers reach authentik. Confirm that your controller passes the headers authentik needs and supports the websocket behavior its login flows use. Also confirm which trusted proxy ranges the cluster network presents to authentik, since a wrong range can break client IP handling and policies.

Enterprise-only features

List the features your requirements depend on, then check each against the edition boundaries before you design around them. Google Workspace and Microsoft Entra ID integrations, mTLS client certificate authentication, privileged access management, password history and enhanced audit logging are listed as Enterprise features. Confirm license terms, subscription pricing and whether FIPS compliance is needed directly with authentik, because the open-source code and the enterprise directory carry different licenses.

Air-gapped image mirroring

If the cluster has no internet access, mirror the authentik server and worker images, the PostgreSQL image if you run one, and every ingress and cert-manager image into your internal registry before install. Disable update checks, startup analytics and error reporting, and confirm that the chart can pull from your registry without changes to pull secrets. Test the mirrored set on a staging cluster, because a missing sidecar image often surfaces only during an upgrade.

How the scope for an authentik Kubernetes install is agreed

DeployOpen agrees the scope for an authentik Kubernetes install in writing before any work starts, and the scope is fixed against named deliverables. The written scope states the cluster prerequisites the install depends on, the external PostgreSQL that replaces the chart's bundled database, how the authentik secrets are generated and stored, the ingress and TLS design, the replica counts for the server and worker deployments, the upgrade runbook, and the handover package. Each of these is a line item with an owner and an acceptance check, so the client can see what is included before a quote is signed. Timelines follow from that written scope and are confirmed in the same document.

The client provides the inputs that the install cannot proceed without. That means cluster access with the permissions needed to create namespaces, deployments, ingress objects and secrets, a named Kubernetes version and distribution, DNS records for the authentik hostname, and the certificate source for ingress. It also means database access: a PostgreSQL instance that the client's team or managed service provides, with a database, a role for authentik, and the connection and TLS settings agreed in advance. The scope should name who approves each of these inputs and by when, and whether the client's platform team or DeployOpen operates the cluster after handover. Confirm the supported Kubernetes minor version against the Kubernetes releases page before the scope is written, since the upgrade runbook depends on it.

Ask for these items to be written into the scope document: the exact Helm chart version and authentik release, the list of values files that will be committed, how secrets are sourced (for example, an external secret store or sealed secrets) and whether encryption at rest is enabled for Kubernetes Secrets, the autoscaling policy for servers and workers, the rollback steps for a failed upgrade, and the owners of the on-call and monitoring handover. Any item the client wants excluded, such as SSO application onboarding, should be listed as out of scope so that later change requests are priced against a clear baseline.

How DeployOpen delivers and supports authentik on Kubernetes

DeployOpen plans, installs and hands over authentik on Kubernetes with the Helm chart inside your own cloud account, data center or air-gapped network. The work is scoped in writing first, built against your cluster and external PostgreSQL, and documented so your platform team can run and upgrade it.

How we scope

We review your cluster version, ingress, storage class, identity requirements and existing PostgreSQL options before agreeing a scope.
The written scope names the authentik version, the Helm chart values we will set and the environments covered.
Most engagements are fixed-scope, with deliverables and timelines agreed in writing before work starts.
Ongoing support, upgrades and continuous testing are available as a retainer if your team wants them after handover.

How we build

We generate and store bootstrap and secret keys in your secret management system, keeping them out of values files committed to Git.
We connect authentik to an external PostgreSQL service you approve, and verify TLS and connection limits before go-live.
We configure ingress, server and worker replicas and autoscaling, then test login, provider flows and failover behavior.
We run a rehearsal upgrade in a non-production cluster so the production upgrade path is tested before it is used.

How we hand over

You receive the Helm values, manifests and runbooks as code in a repository you control, with each setting explained.
Documentation covers secret rotation, backup and restore steps for PostgreSQL, and the upgrade sequence for each release.
We walk your platform and security engineers through monitoring, log locations and the checks that confirm a healthy deployment.
Handover includes a list of open decisions, such as Enterprise feature needs, that your team should confirm with the vendor.

How we support

Support after handover can be agreed as a retainer that covers upgrades, patch reviews and periodic testing of your authentik setup.
We track authentik security releases and the supported version lines, and plan upgrades around the advance notice the project publishes.
Changes to the Helm chart, values or external PostgreSQL go through the same written scope and documented review as the original build.
Security testing of the deployed applications and APIs can be scoped separately, using the same written process.