Autoscaling authentik on Kubernetes: when your login path needs more capacity
When login peaks, admin pages slow down, or the task backlog keeps growing on your Kubernetes cluster, the fix depends on which container is under pressure. authentik servers scale on CPU through the Helm chart's Horizontal Pod Autoscaler (HPA), and workers scale on queued tasks through KEDA. Treat these as two separate decisions, because the server and worker containers do different jobs and fail in different ways.
authentik's architecture splits a deployment into three parts. The server container runs core plus an embedded outpost and handles sign-in requests, the admin interface and outpost traffic. The worker container runs background tasks such as scheduled jobs, file changes and synchronization. Both depend on PostgreSQL, which stores all configuration and data except uploaded files. Since the 2025.10 release, PostgreSQL also carries caching, tasks, sessions and WebSocket functions, so a busy worker or server adds load to the database as well. Before you add replicas, check whether PostgreSQL connections or query latency are the real bottleneck, because more pods will push more connections into the same database.
Use the server HPA when request latency rises with CPU load during login peaks, and confirm that your cluster provides resource metrics before you rely on it. The HPA needs no KEDA or Prometheus for this. Use KEDA for workers when the queue of pending tasks grows while servers stay idle. Keep at least one worker running at all times, because authentik advises this for scheduled tasks and file changes, so the worker scaler must never drop to zero. Ask your team to confirm the current replica settings, scaler triggers and worker concurrency in the authentik autoscaling documentation against the chart version you deploy.
Choosing between the HPA for servers and KEDA for workers
The Helm chart's Horizontal Pod Autoscaler (HPA) scales the authentik server pods on CPU utilization. It reads resource metrics from the cluster's metrics pipeline, so it needs no KEDA and no Prometheus. Because the server container handles login requests, the admin interface and the embedded outpost traffic, CPU load on the servers is a reasonable first signal for user-facing demand.
- Signal used: average CPU utilization across server pods, compared with the target you set in the chart values.
- What it does well: it is the simplest option to run, it is built into Kubernetes, and it reacts to the request load that users actually generate.
- What it misses: CPU does not reflect queued background work, slow database calls that keep threads waiting, or sudden bursts that finish before the HPA's evaluation window.
- Prerequisites to confirm: a working metrics API in the cluster, CPU requests set on the server pods (utilization is calculated against requests), and enough node capacity for new replicas.
- Ask your platform team: whether the chart's minimum and maximum replica values match your PostgreSQL connection budget, since each replica opens its own connections.
Before you rely on the HPA, load test a login-heavy scenario and confirm that CPU rises before users see latency.
KEDA (Kubernetes Event-driven Autoscaling) scales the authentik worker pods on the number of queued tasks rather than on CPU. Workers run scheduled tasks, file changes and other background jobs, so a growing queue is a more direct sign that workers are falling behind than CPU usage would be. KEDA is an extra component you must install and operate, and its scaler reads the queue from the database that authentik uses.
- Signal used: the number of pending tasks in the queue, read through a KEDA scaler that you configure.
- What it does well: it scales workers when work is waiting, including when CPU is low but the backlog is growing.
- What it misses: it does not reduce worker count to zero safely for this workload, so the chart's guidance to keep at least one worker running still applies.
- Prerequisites to confirm: KEDA installed in the cluster, a database connection for the scaler with its own credentials, and a review of how the scaler query affects PostgreSQL load.
- Ask your platform team: who owns the KEDA installation and its upgrades, since KEDA becomes part of your critical scaling path.
Confirm the exact scaler settings in the authentik autoscaling documentation for your chart version before you apply them.
In most clusters the two methods are complementary, not alternatives for the same pods. You can run the HPA on the servers, which needs only resource metrics, and add KEDA only if you also need the workers to follow task backlog. Teams that do not yet operate KEDA can start with a fixed worker count that stays above one, then add the queue-based scaler once they have observed real backlog patterns.
- Decision on servers: use the HPA when CPU reflects your login and admin load and the metrics API is available.
- Decision on workers: use KEDA when backlog, not CPU, shows that workers are the bottleneck.
- Operating cost: KEDA adds a component, a scaler credential and a database query to monitor, so count that effort in your plan.
- Failure mode to watch: a scaler that cannot reach the database leaves workers at their last count, so alert on the scaler's own health.
- Monitoring link: pair either method with worker health checks and queue metrics so you can see whether scaling worked.
Before choosing, check the autoscaling guide, the cluster's metrics setup and whether KEDA is already approved for your environment.
In air-gapped or tightly controlled clusters, the choice between the two methods depends on what you can install and approve. The HPA uses only the cluster's resource metrics, so it fits environments that limit extra components. KEDA requires an installed controller and a scaler that reads the database, which means reviewing its images, its network paths and its service account permissions before deployment.
- Image supply: confirm that the KEDA images, and any metrics components, are mirrored into your internal registry.
- Network paths: the KEDA scaler needs a route to PostgreSQL, so review firewall rules and network policies.
- Permissions: give the scaler the narrowest database role that can read the queue, and store its credentials as Kubernetes Secrets with encryption at rest enabled.
- Change control: treat a KEDA upgrade as a change to the scaling path and test it alongside authentik upgrades.
- Audit evidence: record which scaling method you chose and why, so reviewers can trace the decision.
Confirm your registry mirroring and approval steps with your security team before any scaler is deployed.
When a partner or internal platform team runs the cluster, the scaling choice affects who responds when a scaler fails. The HPA belongs to the standard Kubernetes toolset that most platform teams already monitor. KEDA adds a dependency that needs an owner, an upgrade schedule and alerts. Agree on these responsibilities in the scope before deployment, not after the first incident.
- Ownership: name who maintains the HPA values, the KEDA install and the database credential used by the scaler.
- Alerting: alert on HPA replica counts stuck at the maximum and on KEDA scaler errors.
- Runbook: document how to change replica limits safely during an incident.
- Quote inputs: ask whether the scope includes installing KEDA, writing the scaler configuration and testing it under load.
- Support boundary: confirm whether the cluster team or the authentik team owns the metrics pipeline.
Write these owners into your runbook and confirm them against the written scope.
Scaling options and when each fits
This table compares the four levers for scaling authentik on Kubernetes: the server HPA, KEDA on queued tasks for workers, a fixed minimum worker count and worker concurrency. Read each row for what it controls, when it fits and what it trades away, then confirm the exact keys in the chart values for your version. The main takeaway is that servers and workers respond to different signals and should be tuned separately.
| Option | What it controls | When it fits | Trade-off to confirm |
|---|---|---|---|
| Server HPA on CPU | Number of authentik server pods, based on average CPU use reported by resource metrics | Login and admin traffic rises and server CPU is the clearest signal of load | Needs resource metrics only, but CPU may lag bursty logins; confirm the HPA keys in the Helm values |
| Worker KEDA on queued tasks | Number of worker pods, based on the backlog of queued background tasks | Background work such as event handling and syncs piles up faster than CPU reveals | Requires KEDA installed; confirm the trigger settings and how the queue is read from PostgreSQL |
| Fixed minimum of one worker | Keeps at least one worker running at all times for scheduled tasks and file changes | Almost every production deployment, so scheduled work never stops when the queue is empty | Idle capacity is paid for continuously; confirm the minimum replica key before setting KEDA to scale to zero |
| Worker concurrency | How many tasks each worker process runs at the same time inside one pod | Tasks are I/O bound and one pod has spare CPU and memory headroom | More concurrency adds database connections and memory per pod; check PostgreSQL connection limits first |
| Adding worker replicas | How many worker pods exist in total, independent of concurrency per pod | Backlog spans many tasks and pods can be scheduled across nodes | More pods multiply PostgreSQL connections; size the connection pool before increasing replicas |
| Server replica bounds | Minimum and maximum server pods the HPA may choose | Traffic is predictable enough to set a floor for peak logins and a ceiling for cost | A low ceiling can cause login latency under spikes; a high floor raises baseline cost |
| PostgreSQL capacity | Connections and query throughput shared by all server and worker pods | Any scaling beyond a single server and worker pair | Scaling pods without sizing the database shifts the bottleneck to PostgreSQL; plan the pool and database limits first |
How to set up autoscaling for authentik on Kubernetes
This sequence takes a Kubernetes cluster from a basic authentik install to one where servers scale on CPU load and workers scale on queued tasks, with a worker kept running at all times. Each step ends with a check you can run before moving on.
Confirm metrics and KEDA availability
The platform team checks that the cluster has a working resource metrics pipeline, since the server HPA reads CPU usage from it. Next, they decide whether KEDA is already installed or needs to be added for worker scaling, and confirm that the cluster policy allows installing it. Ask your Kubernetes provider or internal platform team which metrics stack is supported and who approves new cluster-wide controllers. This step is done when resource metrics return pod CPU values and the team has a written decision on KEDA.
Install authentik with an external PostgreSQL
The platform team installs authentik with the Helm chart and points it at a PostgreSQL instance that is managed separately. authentik's Kubernetes guide says the chart's bundled PostgreSQL is for demonstration and test environments, so production autoscaling should not depend on it. Confirm the database host, credentials handling and connection limits with the team that runs PostgreSQL, because autoscaled pods multiply connections. This step is done when the server and worker pods reach ready state and the admin interface loads.
Set CPU requests on server pods
The HPA calculates utilization as a percentage of the CPU request, so the server deployment needs a request value before autoscaling can act. The platform team sets requests in the Helm values based on measured load in a staging environment rather than on defaults. Record the baseline CPU use during a representative login test so the target percentage has a clear reference. This step is done when the server pods show a CPU request in their specification and the metrics pipeline reports a usage value against it.
Enable the server horizontal pod autoscaler
The team turns on the autoscaling options for the server component in the authentik Helm chart, setting the minimum and maximum replica counts and the CPU target. The chart's HPA scales servers on CPU and does not require KEDA or Prometheus, which keeps this change independent of the worker work. Review the chart's current values reference for the exact key names in the version you deploy. This step is done when the HPA object exists and
kubectl get hpashows a current CPU reading instead of unknown.Configure KEDA scaling for workers
Worker pods run scheduled and background tasks, so they scale on queued task backlog rather than CPU. The team creates a KEDA ScaledObject that targets the worker deployment and uses a trigger based on the number of pending tasks in PostgreSQL, which authentik now uses for task queuing. Confirm the trigger query and authentication method with the authentik autoscaling documentation before applying it. This step is done when KEDA reports the ScaledObject as ready and the worker replica count changes after a test burst of tasks.
Keep at least one worker running
authentik advises keeping at least one worker running for scheduled tasks and file changes, so the worker scaler must not drop to zero replicas. The platform team sets the minimum replica count for the worker scaler to one or higher and records that setting in version control. Note that a scaled-to-zero worker would delay scheduled jobs such as certificate and token housekeeping until a task arrives, so test the minimum setting under no load. This step is done when the worker count stays at one or more during an idle period.
Set worker concurrency and verify the backlog
The team sets the number of task threads per worker in the authentik configuration so that each pod processes tasks at a rate the database can support. Higher concurrency per pod and more pods both raise PostgreSQL connection counts, so the change should be checked against the connection limit the database team has agreed. Run a controlled batch of tasks and watch the queue depth and the KEDA-reported replica count fall as tasks complete. This step is done when the backlog drains within the target you agreed with stakeholders and PostgreSQL connection usage stays below its limit.
Why authentik advises keeping at least one worker running
authentik advises keeping at least one worker running at all times because scheduled tasks and file changes are handled by the worker container, not the server. The server accepts requests and queues background work, but if no worker is running, that queued work waits. On a cluster where KEDA scales the worker Deployment on queued tasks, an empty queue is the normal condition, so a scaler left free to reduce replicas to zero will remove the only worker when nothing is pending. Scheduled jobs that fire during that window, and changes to files that authentik watches, may then be delayed until a worker starts again.
The interaction with KEDA scale-to-zero settings is the part to review before you rely on autoscaling. Check whether your ScaledObject allows a minimum replica count of zero, and whether the minimum is set to one. Scale-to-zero is a choice you make in the KEDA configuration, so confirm the value in the manifest or chart values you deploy rather than assuming a default. Ask your platform team to confirm how the ScaledObject's cooldown and polling settings behave with your scheduled task frequency, since a long cooldown can keep an idle worker alive while a short one may still lag behind a scheduled run.
After any scaling event, verify that a worker is running and that scheduled work still executes. Confirm the worker pod is Ready, review its logs for task pickup, and check that a scheduled task you know about completes at its expected time. Repeat this after changes to the minimum replica setting, after chart upgrades, and after a node drain. Treat a missed scheduled run as a signal to revisit the minimum replica count, not as a one-off. The authentik autoscaling documentation is the reference for the current guidance, and it is worth reading alongside your chart version.
Security and operational risks when autoscaling authentik
Scaling authentik adds more server and worker pods, and each pod draws on the same PostgreSQL database, cluster API and secret store. The cards below cover the risks that most often appear once autoscaling is switched on, and the checks to run before you rely on it.
PostgreSQL connection growth
authentik no longer uses Redis, so caching, tasks, sessions and WebSocket functions all run on PostgreSQL. The 2025.10 release notes warn of roughly 50% more PostgreSQL connections after upgrading. Each added server or worker pod opens its own connections, so the connection ceiling can be reached sooner than your load test suggests. Set maximum replica counts with the database limit in mind, and confirm whether a pooler is needed before you raise them.
Bundled PostgreSQL is for test use
The Helm chart's bundled PostgreSQL is intended for demonstration and test environments, and the authentik guide recommends a separately managed PostgreSQL for production. Autoscaling multiplies load on that database, so a bundled instance can fail under the very traffic the autoscaler is meant to absorb. Confirm the database's high availability, backups and connection limits as part of the scaling design, not after it.
Least-privilege RBAC for scaling objects
The HPA and KEDA objects, and the service accounts that KEDA uses to read queue metrics, can change replica counts across a namespace. Grant only the verbs needed to read and scale the authentik workloads, and avoid cluster-wide roles for these controllers. Review who can edit ScaledObject and HorizontalPodAutoscaler resources, because a permissive edit right can silently remove the minimum worker that scheduled tasks depend on.
Pod Security Standards for workers
Worker pods run background tasks and handle sensitive configuration, so they should meet the cluster's Pod Security Standards level for the namespace. Confirm that workers do not run privileged, do not mount host paths they do not need, and drop unneeded Linux capabilities. Autoscaled pods inherit the same template, so a weak template is copied into every new replica.
Secrets stored in etcd
Kubernetes stores Secrets unencrypted in etcd by default. authentik pods read database credentials and its secret key from these objects, so anyone who can read etcd or list Secrets in the namespace can recover them. Confirm that encryption at rest is enabled for etcd, restrict list and watch access to Secrets, and decide whether an external store through the Secrets Store CSI Driver fits your policy.
Pinned versions within supported lines
Autoscaling makes version drift more costly, because a new replica can start from a different image than existing pods during a rolling change. Pin the authentik image tag and keep it within a supported release line, currently 2026.5.x or 2026.8.x according to the security policy. Subscribe to release announcements, since security releases are published at least 24 hours in advance and need a planned rollout.
Autoscaling authentik questions buyers ask
Does the authentik Helm chart autoscaling need KEDA or Prometheus?
No. The server autoscaling in the authentik Helm chart uses a CPU-based Horizontal Pod Autoscaler, which needs resource metrics on the cluster but does not require KEDA or Prometheus. KEDA comes into play for workers, where scaling is driven by queued background tasks. The authentik autoscaling documentation describes both paths. Confirm that your cluster already exposes resource metrics before you rely on the HPA, because without them the autoscaler has no CPU signal to act on.
When is KEDA worth adding to an authentik cluster?
KEDA is worth adding when you need worker capacity to follow the background task queue rather than CPU usage. Workers run scheduled tasks, file changes and other background jobs, so a backlog can build even when CPU looks normal. The authentik documentation advises keeping at least one worker running for scheduled tasks and file changes, so any scaling design should keep a minimum worker count above zero. If your load is mostly interactive logins and your task queue stays short, the HPA on servers may be enough on its own.
How long does autoscaling setup take, and what drives the effort?
No fixed duration is published for this work, so the effort depends on your environment. The main drivers are whether metrics and KEDA are already installed, how many authentik servers and worker types you run, how your PostgreSQL connections are managed, and how much load testing you need before go-live. The 2025.10 release notes warn of roughly 50% more PostgreSQL connections after upgrading, so connection limits and pooling belong in the estimate. Ask any provider for a written scope that lists each of these items separately.
What does the client team need to provide for this work?
You need a Kubernetes cluster you control with a working resource metrics pipeline, a deployed authentik release managed by Helm, and a separately managed PostgreSQL. The authentik Kubernetes guide says the chart's bundled PostgreSQL is for demonstration and test environments and recommends a separate PostgreSQL for production. You also need someone who can approve changes to replica counts, resource requests and PostgreSQL connection limits, plus access to a staging environment where load tests can run. Name these owners before the scope is signed.
Can our own platform team do this in-house?
Yes, if your team already runs Kubernetes, Helm and metrics, and has the time to test scaling under load. The HPA setup is largely configuration, while KEDA adds another controller with its own triggers and failure modes. The harder part is validating that worker concurrency, database connections and scaling thresholds work together under realistic traffic. Weigh that testing effort against your team's current workload before deciding.
What does a fixed-scope DeployOpen engagement cover for autoscaling?
Most DeployOpen engagements are fixed-scope, with scope, deliverables and timelines agreed in writing before work starts. For autoscaling, a written scope would normally name the clusters and authentik components in scope, the HPA and KEDA configuration, worker minimums and concurrency settings, the verification and load test plan, and the handover documentation. DeployOpen does not publish a price list, so a quote follows from that written scope. Ask for each deliverable to be listed separately so you can see what is included and what remains with your team. Ongoing tuning and upgrades can be covered by a retainer.
How does Kubernetes version support affect the autoscaling plan?
Kubernetes version support sets the window in which your cluster can be patched and upgraded without rebuilding the scaling design. The project maintains the three most recent minor releases, and as of September 2026 those were 1.37 (end of life October 28, 2027), 1.36 (June 28, 2027) and 1.35 (February 28, 2027), according to kubernetes.io/releases. Check the Kubernetes releases page for your current version and plan upgrades in order, since the version skew policy requires control plane components to move one minor version at a time. Confirm that your authentik release and chart version support the Kubernetes version you target.
How Kubernetes release timing affects autoscaling plans
Kubernetes release timing matters for autoscaling because the autoscaling setup you build today sits on a cluster version that will leave support. The Kubernetes project maintains the three most recent minor releases, and releases arrive about three times per year on a cycle of roughly 14 weeks. That means a cluster can fall out of support within a year of its last upgrade, and the HPA, metrics pipeline and any KEDA installation need to keep working through each of those moves. Check the supported version list on Kubernetes releases before you choose a cluster version for authentik, and record the end-of-life date for that version next to your authentik release.
The version skew policy governs how the control plane and kubelets can be upgraded relative to each other. kube-apiserver must be upgraded one minor version at a time, ahead of kube-controller-manager, kube-scheduler and the kubelets, and kubelets may run up to three minor versions older than kube-apiserver. For autoscaling, this affects when you change the HPA target, the metrics server and KEDA versions, because each of those components has its own compatibility range with the cluster. Confirm the compatibility statement for each add-on with its own documentation before you upgrade the cluster, rather than assuming the latest chart will match your control plane.
Plan autoscaling changes as part of each cluster upgrade, not as a separate project. Before an upgrade, confirm that the HPA for the authentik server still reads CPU metrics, that KEDA is supported on the target version if you use it for workers, and that the worker deployment keeps at least one replica during rollout. Test the upgrade in a non-production cluster with a load pattern close to your peak logins. Schedule the work against the end-of-life dates on the release page so you are never forced to upgrade under an incident, and confirm the authentik chart version you run also supports the new Kubernetes minor release.
How DeployOpen scopes and delivers authentik autoscaling
DeployOpen plans, implements, hardens, documents and supports self-hosted open-source platforms inside your own infrastructure, including your Kubernetes clusters. For authentik autoscaling, we start from your measured login load, your cluster's metrics setup and your database capacity, then agree the scope in writing before any change is made to your environment.
How we scope
- Review your authentik version, Helm chart values, cluster metrics stack and whether KEDA is already installed or permitted.
- Confirm your PostgreSQL setup, connection limits and whether the database is managed separately from the chart.
- Agree in writing which workloads scale, the replica limits, the worker queue signal and the acceptance tests.
How we build
- Configure the server HPA from the Helm chart with CPU targets, minimum and maximum replicas, and resource requests that match your nodes.
- Set up KEDA scaling on queued tasks for workers, keeping at least one worker running for scheduled tasks and file changes.
- Tune worker concurrency against your PostgreSQL connection budget, then load test the login path and record the results.
How we hand over
- Deliver the Helm values, KEDA objects and manifests in your version control, with a short runbook for each scaling rule.
- Document the thresholds, the reasons behind them and the signals to review when login latency or queue depth changes.
- Walk your platform and security teams through rollback steps and the checks to run after each authentik upgrade.
How we support
- Engagements are fixed-scope, with scope, deliverables and timelines agreed in writing before work starts.
- Ongoing support, upgrade assistance and continuous testing are available as a retainer after handover.
- Ask us to confirm scaling behavior against each new authentik release before your team applies the upgrade.
