authentik high availability: HA design guide

How to design authentik high availability once Redis is gone

For a login gateway that many applications depend on, availability now depends mainly on the PostgreSQL layer, the server and worker containers, and the outposts that sit in front of your applications. Since the 2025.10 release, authentik no longer uses Redis. Caching, background tasks, sessions and WebSocket functions run on PostgreSQL instead. That makes the database the shared dependency for nearly every login, token issue and background job, so the design starts there. If PostgreSQL is slow or unavailable, every component above it degrades at once.

Moving those functions into PostgreSQL makes the design harder than it looks. The 2025.10 release notes warn of roughly 50% more PostgreSQL connections after upgrading, so size the connection budget across every server and worker replica before you add capacity. The authentik Kubernetes guide says the PostgreSQL bundled with its Helm chart is for demonstration and test environments and recommends a separately managed database for production. Confirm with authentik how sessions and in-flight background tasks behave when a replica is terminated during a rolling restart, then test that exact sequence in a non-production environment before you rely on it.

Uploaded files sit outside the database. The authentik architecture documentation states that PostgreSQL stores all configuration and data except uploaded files. If server and worker replicas do not all read the same file storage, some nodes will serve broken or missing uploads, and background work that handles files may fail on some workers. Decide the storage model before you choose replica counts: a shared volume, object storage or another option your platform supports. Confirm with authentik which containers mount that path and which storage backends are supported, and include the file store in your backup scope, not just the database.

Embedded outposts are tied to the server. The server container runs core plus an embedded outpost, so restarting or scaling server replicas also affects the traffic that embedded outpost handles. For simple deployments this may be acceptable. For applications where proxy or LDAP availability matters, plan separate outposts with their own replicas, and confirm how they authenticate to the server using outpost tokens. Set the upgrade order so the server, workers and outposts stay within supported version combinations, and rehearse a failover for each outpost type before cutover.

Which authentik components need redundancy

An authentik deployment depends on five parts that can fail independently: the server, the worker, PostgreSQL, outposts and uploaded file storage. Each one has a different failure impact and a different redundancy requirement, so plan them as separate decisions rather than one uptime target.

Server container

The server container runs authentik core and an embedded outpost, so it serves login, the admin interface and the API. If it goes down, sign-in stops for every application that depends on it. Redundancy means running more than one server replica behind a load balancer with health checks. Confirm in the architecture documentation for your chosen release how sessions and WebSocket connections behave when a replica is replaced, since that determines whether users are signed out mid-session.

Worker container

The worker container runs the background tasks that authentik schedules and processes after requests complete. If no worker is running, those tasks queue up or stop, and the effects often appear later and are easy to miss. Redundancy means running more than one worker so one can be replaced without pausing task processing. Check that every worker connects to the same PostgreSQL database and that task backlog is monitored and alerted on.

PostgreSQL database

PostgreSQL holds all configuration and data except uploaded files, including users, applications and flow definitions, so it is the most critical dependency. The 2025.10 release removed Redis and moved caching, tasks, sessions and WebSocket functions into PostgreSQL, and its release notes warn of roughly 50% more database connections after upgrading. Plan for a separately managed, highly available PostgreSQL with connection headroom. The Kubernetes guide states that the bundled chart database is for demonstration and test use.

Separately deployed outposts

Outposts run apart from the server when proxy, LDAP, RADIUS or RAC endpoints sit near protected applications or in a separate network zone. An outpost stops serving its protocol when its instances are down, even if the core server is healthy. Redundancy means running more than one instance per outpost in each location, with tokens and provider assignments managed consistently. Confirm the outpost upgrade order against the release notes for your version before changing running instances.

Uploaded file storage

Uploaded files are stored outside PostgreSQL, so restoring the database does not recover them. If the storage location is lost or unreachable, those files are missing even though the rest of the deployment runs. Redundancy means choosing storage that every server and worker replica can reach, and that is replicated or backed up on its own schedule. Confirm in your deployment configuration where uploads are written and which storage options your release supports, then include files in backup and restore tests.

Which deployment and database choices fit your uptime target

This table compares the deployment, database, outpost and storage choices that shape authentik availability. Read each row against the uptime you need, because a single-host setup and a multi-replica setup fail in different ways. The main takeaway is that a separately managed PostgreSQL is the foundation for any production target, since it carries every configuration record, session and background task after the Redis removal.

Choice	When it fits	Operational cost
Docker Compose on one host	Test setups and small-scale production, where a single host with at least 2 CPU cores and 2 GB of RAM is acceptable and a short outage during host maintenance is tolerable	Lowest setup effort, but the host, its disks and its restarts become your single point of failure
Kubernetes with Helm	Production targets that need several server and worker replicas, rolling upgrades and node-level failover across a cluster you already run	Requires cluster skills and monitoring, and a chart upgrade plan that accounts for breaking changes between releases
Bundled PostgreSQL in the Helm chart	Demonstration and test environments only, as the chart documentation states	Quick to start, but database backup, failover and version upgrades fall to your team with no separate recovery path
Separately managed PostgreSQL	Production, because it lets backup, replication and failover follow your existing database standards	Recurring database hosting and on-call cost, plus connection capacity planning, since the 2025.10 release notes warn of roughly 50% more connections after upgrading
Embedded outpost in the server container	Single-site deployments where the applications authentik protects can reach the server directly	Simplest to run, but outpost capacity and failure follow the server container, so scaling the server also scales the outpost
Separately deployed outposts	Applications in other networks or regions, or any case where outpost load must scale independently of the core	Extra workloads to deploy, monitor and upgrade in step with the server version, plus token management for each outpost
Single server container	Low traffic or early pilots where one restart window is acceptable	A restart or failed upgrade stops logins, so maintenance windows must be planned and communicated
Several server and worker replicas	Production targets that must survive a single pod or container failure during business hours	Needs a load balancer, shared session-safe configuration and tested rolling upgrades, which add engineering and testing time
Shared storage for uploaded files	Several replicas that must all serve the same uploaded files, such as branding assets or custom templates	Storage service fees and access-mode decisions, and the file system must be reachable from every replica
Local volume for uploaded files	Single-container deployments where one host holds the only copy of uploaded files	No extra storage service, but files are lost with the host unless they are included in your backup and restore tests

Build sequence for authentik high availability

This sequence takes an authentik deployment from a single server to one where a server, worker or outpost can be restarted without losing user sessions. Each step ends with a check, so the team confirms one layer works before the next depends on it. The work runs in the client's own infrastructure, with database and storage layers managed by the teams that already run them.

Provision a separately managed PostgreSQL with failover
PostgreSQL is the central dependency for authentik. It stores all configuration and data except uploaded files, and since the 2025.10 release it also carries the caching, tasks, sessions and WebSocket functions that Redis used to handle. Your database team or a managed database service provisions a PostgreSQL instance with automated failover and a stable connection endpoint. The bundled PostgreSQL in the Kubernetes chart is intended for demonstration and test environments, so it should not be used here. Done when a controlled failover promotes a standby and authentik reconnects through the same endpoint without manual changes.
Size PostgreSQL connection limits for the upgrade
The 2025.10 release notes warn of roughly 50% more PostgreSQL connections after upgrading, because Redis is gone and its work now runs in the database. Record current connection counts before changing anything. Then total the connection pools of every server replica, worker replica and outpost that will connect, add headroom for failover and maintenance sessions, and set the database connection maximum above that total. Done when a load test of sign-in and token issuance keeps the connection count below the limit at peak.
Deploy two or more server replicas behind a load balancer
Each server container runs authentik core with an embedded outpost. Every replica must point at the same PostgreSQL endpoint and use an identical secret key and configuration, which you should confirm against the installation guide for your release. Place two or more replicas behind a load balancer that routes traffic and removes unhealthy members. The Docker Compose guide lists 2 CPU cores and 2 GB of RAM as the minimum for a host and positions Compose for test and small-scale production, so treat that as the floor for a single host. Done when sign-ins succeed through the load balancer while one replica is stopped.
Run worker replicas alongside the servers
The worker container runs background tasks, so it needs its own replicas rather than sharing the server container's lifecycle. Deploy at least two worker replicas that connect to the same database and shared storage as the servers. Confirm the worker count in the upgrade notes for your release, since task handling changed when Redis was removed. Done when a background task, such as sending an email or running a scheduled sync, completes after one worker replica is stopped and the remaining worker picks it up.
Place uploaded files on shared storage
Uploaded files are the one category of data that PostgreSQL does not hold. If a server or worker replica stores an upload on its local disk, other replicas cannot serve it. Choose a shared storage option that your platform team already supports and mount it at the same path on every server and worker replica. Check the media storage settings in the documentation for your release before you configure the mount. Done when a file uploaded through one replica can be retrieved through another after the first replica is stopped.
Deploy outposts with their own redundancy
Outposts connect to the authentik server and serve protocols such as LDAP, RADIUS or the proxy provider close to the applications that use them. Run more than one instance of each separately deployed outpost so that one can be restarted without stopping the application it serves. Store outpost tokens in your secret manager, not in configuration files kept in source control, and confirm the outpost version matches the server release line. Done when an application keeps authenticating after one outpost instance is stopped.
Configure health checks and WebSocket proxying
The load balancer and reverse proxy need health checks that call authentik's health endpoint, so that failing replicas are removed from rotation. Confirm the health check path in the documentation for your release. Configure the proxy to forward WebSocket upgrade requests and set idle timeouts long enough that live connections are not dropped early. Done when a health check marks a stopped replica as unhealthy within the configured interval, and a browser session holding a WebSocket connection stays live through the proxy during a test window.
Confirm a rolling restart drops no sessions
Before go-live, test the design with a rolling restart. Restart one server, worker or outpost at a time, and wait for each to return healthy before moving to the next. Keep test users signed in during the restarts and have them run sign-in, token refresh and an application launch. Review logs for connection pool errors. Done when every restart completes, no test session is lost, and the results are recorded so the test can be repeated after each upgrade.

Why the Redis removal changes your database plan

The authentik 2025.10 release removed Redis entirely. According to the release notes, caching, background tasks, sessions and WebSocket functions moved to PostgreSQL. Earlier deployments could treat the database mainly as the store for configuration and data, with short-lived state held elsewhere. Now every session check, queued worker job and live connection reaches PostgreSQL. A database outage no longer only blocks configuration changes. It can stop sign-ins and background work at the same time. The high availability design should start from that fact, because the database is now part of the login path.

Both the server and worker containers depend on PostgreSQL for live operation, so the database needs the same planning as the application tier. Confirm how your chosen PostgreSQL service handles failover, how long a switchover takes, and whether authentik reconnects cleanly afterward. Decide whether a connection pooler sits between the containers and the database, and confirm that its pooling mode is compatible with authentik's connection behavior. Schedule database maintenance windows with the same care as application upgrades, since a patch restart now affects sign-ins. Monitor connection counts, lock waits, replication lag, slow queries and the worker task backlog, and set alerts on each.

The 2025.10 release notes warn of roughly 50% more PostgreSQL connections after upgrading. Treat that figure as a sizing input, not a guarantee for your environment. Before upgrading, record the connection count your current deployment uses at normal and peak load, then model the increase across every server and worker replica you run. Check the headroom in the database's connection limit, any pooler limits and the per-replica pool settings. If you are migrating from an older release, confirm the connection change against the release notes for your starting version and for your target version, because the figure applies to the specific upgrade path those notes describe.

Verify the design before production traffic depends on it. Run a load test in staging with the planned replica counts, then force a database failover during active sessions and confirm which users are signed out, how quickly workers resume, and whether queued tasks complete. Note that the Docker Compose guide positions that setup for test environments and small-scale production on a host with at least 2 CPU cores and 2 GB of RAM. The Kubernetes guide states that its bundled PostgreSQL is for demonstration and testing, and recommends a separately managed PostgreSQL for production. Plan for that separate database from the start, and ask your partner or platform team to confirm it in your environment.

What drives the effort of an authentik HA design

This table lists the factors that change how much design, build and run work an authentik high availability setup requires, and how each one can be kept in check. Read each row as a question to answer early, since most drivers shape the database, outpost and testing decisions together. The main takeaway is that connection capacity in PostgreSQL, since Redis is gone, and the number of environments usually matter more to effort than raw user count.

Driver	Why it changes the work	How to keep it down
User count and login peaks	Higher concurrent logins raise server and worker sizing, PostgreSQL connection demand and the load test scope. Peaks such as start-of-shift logins matter more than daily totals.	Measure peak login rate from current systems, size against peaks rather than averages, and confirm sizing with a load test before go-live.
Number of applications and outposts	Each provider, application and outpost adds configuration to version and test, and each outpost deployment needs its own health checks and token handling.	Standardize on a small set of provider types, template outpost deployments, and group applications by protocol to reduce duplicate work.
Number of environments (production, staging, disaster recovery)	Every environment needs its own database, secrets, networking and backup jobs, and the disaster recovery site must stay configuration-aligned with production.	Build one reproducible deployment definition and promote it through environments, keeping only environment-specific values outside the shared code.
Database service choice and existing managed PostgreSQL	Running PostgreSQL inside the cluster means the team owns replication, failover, patching and backups. A managed service with an existing operations team shifts much of that work. The Kubernetes guide recommends separately managed PostgreSQL for production.	Check whether the organization already runs managed PostgreSQL with tested failover, and confirm connection limits and pooling needs before choosing the service.
Storage for uploaded files	Uploaded files such as branding assets are stored outside PostgreSQL, so they need shared, durable storage across server replicas and must be included in backup and restore scope.	Use shared storage that all replicas can reach, document where files live, and add them to the same restore test as the database.
Compliance evidence for backup and restore	Assessors and internal audit typically ask for recorded restore tests, retention settings and access logs. Producing this evidence repeats with each test cycle.	Agree the evidence list before design, automate restore test logging, and store results with the change records. Confirm required evidence with your auditor.
Frequency of supported-release upgrades	Each release line has a support window, and major changes such as the Redis removal in 2025.10 required database connection and configuration review. Outpost versions must match the server.	Plan a fixed upgrade cadence in a staging environment, read release notes before each change, and upgrade outposts in the same window as the server.

How HA differs across Compose, Kubernetes and air-gapped hosts

Docker Compose suits test environments and small-scale production. The authentik Compose guide calls for a host with at least 2 CPU cores and 2 GB of RAM as a starting point. The stack runs a server container (core plus an embedded outpost), a worker container and PostgreSQL. Availability depends on the host, so a single host remains a single point of failure for the whole stack.

Replicas: you define the server and worker services in the Compose file. Compose does not move containers to another host or fail over automatically.
PostgreSQL: the database runs on the same host unless you point the stack at an external instance. Backups, failover and version upgrades are your responsibility.
Outposts: the embedded outpost runs inside the server container. Standalone outposts for proxy or LDAP need their own containers, and a second host is needed for redundancy.
Storage: volumes hold PostgreSQL data and uploaded files. The Compose file does not replicate those volumes to another host.

Before you rely on this model, confirm with the platform team how host failure is recovered, where backups are stored and whether the host can be rebuilt from your restore procedure.

How to protect the HA layer: credentials, tokens and recovery paths

Every authentik replica depends on the same database, the same secret key and the same administrator access paths, so a weakness in one place affects the whole deployment. The cards below cover each credential, token and recovery path, with the checks to confirm before go-live and after each change.

Database credentials and TLS

Every server and worker container connects to one PostgreSQL instance, which holds all authentik configuration, user records and sessions except uploaded files. Use a dedicated database role limited to the authentik database, and store its password in a secrets manager that injects it at runtime. Encrypt these connections with TLS and verify the server certificate on each replica, so a certificate rotation does not silently break a single container. Confirm connection limits with your PostgreSQL sizing, because the 2025.10 release notes warned of roughly 50% more connections after authentik removed Redis.

Shared secret key across replicas

All server and worker containers must read the same secret key, because data written by one container has to be readable by the others. A replica that starts with a different key can produce failures that look intermittent, such as sessions or tokens that work on some requests and fail on others. Set the key once in your secrets store, deliver the identical value to every server and worker, and check each container's configuration after every redeploy. Confirm in the authentik documentation for your release what the key protects, and write a rotation procedure before you need one.

Outpost tokens on every move

Outposts authenticate to authentik with tokens, so a token is a credential for whatever host runs the outpost. When an outpost moves to new hosts, a new cluster or another region, rotate its token and revoke the old one in the same change window. A copy of a token left on a decommissioned node stays valid until you revoke it. Check which outposts run embedded in the server container and which run separately, because the embedded outpost follows the server deployment. Record each outpost's location, owner and token issue date so rotations can be traced during an audit.

Restricted access to backups

Database backups contain the same sensitive material as the live system, including configuration, user data and stored credentials, so they need the same access controls. Limit who can read, restore or download backup files, keep backup encryption keys separate from the backups, and log every restore. Test a restore into an isolated environment on a regular schedule. Confirm that the secret key and database credentials needed to use a restored copy can be recovered through a separate, audited process, so the recovery path does not become a bypass.

Admin access during a failure

A recovery plan only works if administrators can sign in while the primary node or region is down. Keep more than one named administrator account, each with MFA enrolled on a device that does not depend on the failed location. Store break-glass credentials sealed offline, document who may use them, and require that every use is reported. Confirm that DNS, the identity source for administrators and the VPN or network path used to reach the admin interface do not all depend on the same region as authentik.

Patching on supported release lines

The authentik security policy lists 2026.5.x and 2026.8.x as the supported versions that receive security fixes, so plan upgrades to stay within those lines. Roll server, worker and outpost upgrades in a defined order, and read the release notes for breaking changes before each move. The project announces security releases at least 24 hours in advance, so keep a named person on call to schedule a maintenance window and a tested rollback. Confirm that your support agreement and staffing cover that window.

How to test that authentik fails over and restores cleanly

Write the pass criteria before anyone stops a container. A failover test only proves something if the team agreed in advance what counts as success, such as which login flows must keep working during a fault, which error messages are acceptable to users, and how many failed sign-ins are tolerable before the test is marked failed. Agree these criteria with the application owners and with the business owners who will be accountable for outages. Recovery time and recovery point targets must come from those owners. This page does not set them, so confirm them before the first test run and write them into the test record. Without agreed targets, a team can report a pass that the business would not accept.

Start with the failure modes that matter most for the design. Stop one server replica while test users hold active sessions and an application is mid-login, then confirm that the surviving replica serves new requests and that existing sessions behave as your design expects. Stop one worker container and check that background tasks, such as directory sync or email delivery, queue and resume rather than vanishing. Then force a PostgreSQL failover, since authentik keeps its configuration, sessions and cached data in PostgreSQL after the removal of Redis in the 2025.10 release. Watch login continuity from a scripted client that signs in every few seconds and logs each result with a timestamp.

Test the outposts separately, because an outpost that loses its connection to the server can break access for the applications behind it even when the core service is healthy. Take an embedded or standalone outpost offline and confirm what the fallback is in your design, whether that is a second outpost instance, a documented bypass for administrators, or a clear failure page. Then run a full restore into a clean environment. Restore the PostgreSQL backup and the uploaded media files, bring up server and worker containers at the same supported version, and complete a login and an application check against at least one OIDC or SAML application. Verify the restored environment against the pass criteria, not against memory of the original.

Record every run in a test log that holds the date, the authentik version, the commands used, the timestamps, the observed behavior and the pass or fail result against each criterion. Keep the log with the runbook so that auditors and the next engineer can see what was tested and what changed. Repeat the restore test after every upgrade, and treat the upgrade as incomplete until the restore test passes on the new version. The security policy lists 2026.5.x and 2026.8.x as the supported release lines, and security releases are announced at least 24 hours in advance, so schedule the restore test to fit that window. Ask your implementation partner or internal team to confirm which tests they will run in each cycle and who signs off on the result.

What to monitor, back up, upgrade and document after go-live

This table lists the operational areas that keep an authentik high availability deployment healthy after launch, with the work each one needs and the team that should own it. Read it as a split of duties between the platform team, the database owner, the application owners and the security or compliance function. The main takeaway is that redundancy alone does not protect uptime: monitoring, tested restores and a current runbook are what let the on-call team recover quickly and let auditors trust the design.

Area	What to do	Who owns it
PostgreSQL connections and replication lag	Track active connections against the limit, since the 2025.10 release notes warn of roughly 50% more connections after upgrading. Alert on replication lag between primary and standby, and confirm failover behavior before go-live.	Database team
Server and worker health	Watch health checks, restarts and resource use for every server and worker replica. Alert when background tasks back up, because workers handle tasks that PostgreSQL now carries in place of Redis.	Platform engineering
Outpost connectivity	Monitor each outpost's connection to the server and its health status. Confirm each outpost has a redundant instance reachable from the network segment where its applications run.	Platform engineering with application owners
Login error rates and events	Set baseline login failure, MFA failure and flow error rates. Forward authentik event logs to your SIEM so spikes and administrative changes are reviewed.	Security operations
Scheduled backups of PostgreSQL and uploaded files	Schedule regular PostgreSQL backups and back up the media volume holding uploaded files, since PostgreSQL stores everything except those files. Keep copies outside the cluster and record retention periods.	Database team with platform engineering
Periodic restore tests	Restore backups into an isolated environment on a set schedule, start the server and worker, and confirm logins and an outpost connection work. Record the time taken and any gaps found.	Platform engineering, reviewed by compliance
Upgrades on supported release lines	Plan upgrades within the supported release lines named in the security policy, and read breaking-change notes first. Upgrade outposts alongside the server so versions stay compatible, and test in staging.	Platform engineering
Runbook and architecture record	Maintain a runbook for failover, restore and outpost recovery, plus an architecture record covering replicas, database topology, backup locations and configuration as code. Confirm the evidence format with your auditor before the first assessment.	Platform engineering, with compliance and on-call teams

Questions teams ask before building authentik high availability

How much does an authentik high availability design cost?

The cost depends on the environment you build in, mainly the number of server and worker replicas, the PostgreSQL service you run, the load balancer and DNS setup, where outposts are placed, and how much failover and restore testing is in scope. Who gets paid: your own staff or cloud and data center providers for infrastructure, database services and monitoring, and DeployOpen only if you engage it under a written, fixed-scope quote. Recurring costs include infrastructure, database fees, monitoring and upgrade effort. One-time costs include design, build, testing and handover. When you request a quote, ask for line items covering infrastructure assumptions, the database option, outpost count, test scope, documentation, and support terms. For edition costs, see the cost of ownership topic.

How long does authentik high availability take to build?

The duration depends on your environment: whether PostgreSQL is already run as a highly available service, whether you host on Kubernetes or virtual machines, how network paths and firewalls are set up, how many identity sources and applications need integration, and how many outposts are required. Failover and restore testing takes additional time because it needs maintenance windows, stakeholder sign-off and evidence capture. DeployOpen does not publish fixed durations, so ask for a timeline in the written scope. The implementation plan topic describes the phases, which helps you compare your own estimate with a partner's proposal.

Can our in-house team build authentik high availability alone?

Often yes, if your team already runs PostgreSQL clusters, container platforms and load balancers, and has at least one person who has operated an identity provider before. The gaps are usually specific: sizing database connections after the Redis removal, placing outposts close to the applications they serve, designing backup and restore tests that prove recovery, and setting change control for security releases. Review those areas against your skills before deciding. DeployOpen can plan, build, harden, document and support the deployment inside your infrastructure, and it can take the parts your team lacks while your staff keep ownership of the system.

What does an authentik high availability project need from our database, network and identity teams?

Database team: a PostgreSQL service with replication, automated failover, backups and enough connection capacity, which your database owners must size and operate. Network team: load balancer and TLS termination, DNS records, firewall rules that let outposts reach the core service, and certificate handling. Identity team: owners for upstream identity sources, groups, flows and MFA policy. Change owners: someone who approves upgrades and security releases. The authentik security policy announces security releases at least 24 hours in advance, so the change process must be able to respond on short notice. Agree these owners in the scope before work begins.

Is the Enterprise edition required for authentik high availability?

Confirm this with authentik before you design, because the answer determines your license cost. The project's repository is mostly under the MIT license, while code in the enterprise directory falls under a separate enterprise license. The authentik pricing page lists multi-instance deployment support as an extra included with Enterprise Plus. Confirm exactly what that covers, such as deployment guidance, support hours or escalation paths, before relying on it in a plan. Edition choices, per-user and infrastructure costs, and when each option makes sense are covered in the cost of ownership topic.

Does the bundled PostgreSQL in the authentik Helm chart work for production?

No, the Kubernetes installation guide says the PostgreSQL bundled with the chart is for demonstration and test environments. It recommends a separately managed PostgreSQL for production. For high availability, this matters more than usual because the database carries the workload that Redis used to handle. Plan a managed or independently operated PostgreSQL cluster with its own backup, failover and monitoring, and connect authentik to it through a stable endpoint. Confirm the database design with your database team before any production cutover.

Why did the Redis removal change authentik high availability planning?

Release 2025.10 removed Redis entirely and moved caching, background tasks, sessions and WebSocket functions to PostgreSQL. The release notes warn of roughly 50% more PostgreSQL connections after upgrading. That makes the database the central dependency for uptime, so a design must cover connection budgeting and pooling, failover behavior, and load testing against realistic session counts. Runbooks written for Redis-based deployments may be out of date. Review them against the current release line before an upgrade, and treat the database as a critical component in backup and restore testing.

How DeployOpen scopes, builds and hands over authentik HA

DeployOpen plans, builds, documents and supports self-hosted authentik high availability inside your own cloud accounts, data centers or air-gapped networks. Each engagement starts from a written, fixed scope that names the replicas, database, outposts and recovery tests included.

How we scope

Map current authentik version, edition and every provider type that must stay available during failures
Agree the target topology for server and worker replicas, PostgreSQL and outpost placement in writing
Record recovery objectives, backup retention and restore test expectations that the written scope will cover

How we build

Deploy server and worker replicas on your platform with configuration kept reproducible across environments
Provision PostgreSQL as a separately managed high availability service, sized for the connection increase noted after the Redis removal
Install and verify outpost redundancy, then run failover and backup restore tests before go-live

How we hand over

Deliver architecture diagrams, runbooks for failover, scaling and restore, and the configuration as code used
Walk your platform and security teams through restore drills and the monitoring signals they should watch
Confirm access, secrets handling and outpost token ownership so your team operates the cluster independently

How we support

Offer ongoing support, upgrades and continuous testing as a retainer after handover, if your team wants it
Plan upgrades against the supported release lines published in the authentik security policy
Repeat backup and restore testing on a schedule agreed in the retainer scope

authentik high availability