Authentik high availability looks different than it did a year ago, and a lot of what's written about it is now wrong in a specific way: Authentik removed Redis entirely as of the 2025.10 release. Caching, background tasks, WebSocket connections, and the embedded outpost all moved to PostgreSQL. If a guide still has you standing up Redis Sentinel for Authentik HA, it's describing an architecture that no longer exists.
This covers what HA actually requires now: scaling server and worker instances, what PostgreSQL needs to handle without Redis absorbing part of the load, shared storage across instances, and the load balancer and version details that are easy to get wrong.
Quick answer
Jump to a section
Why Authentik dropped Redis
The migration ran across four releases over about 18 months: advisory locks moved to PostgreSQL in 2024.6, session storage in 2025.4, background tasks in 2025.8, and the rest, caching, WebSocket connections, and the embedded outpost, in 2025.10. By that last release, Redis wasn't doing anything anymore.
The stated reasoning is worth knowing because it explains why this isn't coming back: Redis's 2024 licensing changes pushed the team to move proactively, and Redis HA itself is genuinely hard, requiring Sentinel or cluster sharding logic duplicated across Authentik's Go and Python components. Fewer moving parts for a self-hosted identity provider was the actual goal, not a performance chase.
Not free of trade-offs
Scaling server and worker nodes
Both the server (handles API and UI traffic) and worker (background tasks, scheduled jobs) processes are stateless, and Authentik doesn't put any special requirement on how many of each you run. Scale them independently: more server replicas if login and API traffic is the bottleneck, more worker replicas if scheduled sync jobs or outpost communication is what's backing up.
# docker-compose.yml, illustrative
services:
server:
image: ghcr.io/goauthentik/server:2026.x
command: server
deploy:
replicas: 3
worker:
image: ghcr.io/goauthentik/server:2026.x
command: worker
deploy:
replicas: 2On Kubernetes, the equivalent is just setting replicaCount in the Helm chart's server and worker sections and letting your ingress or load balancer spread traffic across the resulting pods.
PostgreSQL for authentik ha
This is the part that changed the most. PostgreSQL now carries everything Redis used to handle, and Authentik's own docs are direct about the consequence: expect roughly 50% more database connections than a pre-2025.10 install needed. Size your instance and connection pool with that in mind, not against old sizing guidance written before the migration.
| Consideration | What to do |
|---|---|
| Connection count | Budget for ~50% more than older Authentik versions, size RDS/Aurora or your pooler accordingly |
| Connection pooling | PgBouncer or Pgpool are both supported; without one, connection count climbs fast with every added replica |
| Read replicas | Supported for query offloading; adding or removing one requires a restart, not a hot-reload |
| TLS | If your Postgres requires TLS, Authentik now needs TLS 1.3 or the Extended Master Secret extension to connect |
A managed Postgres service (RDS Multi-AZ, or Aurora) with a pooler in front is the practical answer here rather than self-managing replication by hand, the failover and backup story is already solved there.
Shared storage across instances
Local disk storage for uploaded media (icons, branding assets) and certificates works for one instance and breaks the moment you add a second, each server would see a different set of files. Switch the storage backend to S3 or an S3-compatible service before scaling out, not after someone notices a missing logo on half the instances.
AUTHENTIK_STORAGE__MEDIA__BACKEND=s3
AUTHENTIK_STORAGE__MEDIA__S3__BUCKET_NAME=your-authentik-media
AUTHENTIK_STORAGE__MEDIA__S3__REGION=us-east-1Load balancing and outpost versions
Put a standard load balancer in front of the server replicas with a health check against Authentik's health endpoint, nothing exotic needed since the instances are stateless. The detail that actually causes incidents is version parity: the core Authentik instance and every outpost (proxy outposts, LDAP outposts, whatever you're running) have to be on matching versions. Upgrade them together, not the core first and outposts "whenever," or you'll hit compatibility issues that look like an HA problem but are really a version mismatch.
Common HA pitfalls
- Following a guide that still mentions Redis: if it's not dated for 2025.10 or later, the architecture it describes is out of date. Treat Redis-based Authentik HA advice as legacy content.
- Undersized Postgres connection limits: the 50% increase is real, not a worst-case estimate. Hitting connection limits under load looks like random 500s, not an obvious capacity message.
- Local disk storage after scaling out: inconsistent branding or missing certificates across instances almost always traces back to this.
- Mismatched outpost versions: covered above, and worth checking first whenever something HA-adjacent breaks after an upgrade.
If you haven't deployed Authentik at all yet, start with our Authentik developer guide or the single-click AWS setup, both cover the single-node install this article assumes you're scaling up from. And if the operational overhead of running any IdP HA yourself is the real concern, it's worth comparing against Keycloak, which has its own, different HA story built around its clustering model rather than a stateless-app-plus-Postgres pattern.
Frequently Asked Questions
Do I still need Redis for Authentik high availability?
No, not on a current install. Authentik fully removed Redis as of the 2025.10 release, caching, background tasks, WebSocket connections, and the embedded outpost all moved to PostgreSQL. If you're planning around Redis Sentinel or a Redis cluster for HA, that's outdated advice for any recent version.
What does an authentik ha deployment actually need instead of Redis?
Multiple stateless server and worker instances behind a load balancer, a PostgreSQL setup that can handle the connection load (it's real, roughly 50% more connections than pre-2025.10 versions), and S3-compatible shared storage for media and certificates so every instance sees the same files.
What counts as an authentik production deployment versus a basic install?
A basic install is one server container, one worker, local disk storage, and a single Postgres instance, fine for testing or a small team. Production means multiple server/worker replicas, PostgreSQL sized and pooled for the connection count, S3 storage instead of local disk, and a load balancer with real health checks.
Does authentik postgresql redis scaling still apply to newer versions?
Only the PostgreSQL half. Scaling now means PostgreSQL read replicas, connection pooling, and enough capacity for roughly 50% more connections than older versions needed, since Postgres absorbed everything Redis used to handle. There's no Redis layer left to scale.
Can I run authentik server and worker as separate scaled components?
Yes, that's the intended HA pattern. Both are stateless, so you can run more worker replicas than server replicas (or the reverse) depending on whether your bottleneck is API traffic or background task processing.
What breaks if I upgrade an old Redis-based Authentik install to a Redis-free version?
Nothing breaks automatically, but outposts and the core instance must match versions exactly, mismatched versions between them isn't supported. Remove Redis-related config values, and if you're on Docker Compose, upgrade with --remove-orphans so the old Redis container actually gets cleaned up instead of sitting there unused.
Skip Building HA From Scratch
Launch a pre-configured Authentik server on AWS as your starting point, then scale server and worker replicas behind a load balancer as traffic grows.
Get Authentik on AWS Marketplace
