High availability

High availability refers to system design that minimizes downtime even in the event of failures or disruptions.

authentik supports high availability in several ways:

• Multiple instances of the server and worker can be run in parallel, allowing for redundancy.
• The authentik database is PostgreSQL, which has extensive support for different highly available setups.
• Both authentik and PostgreSQL support active-passive deployments.

Parallel server and worker instances

authentik server and worker instances are stateless. All session state and configuration data is stored in the database. This statelessness makes it easy to horizontally scale authentik deployments by adding more server and worker instances, ensuring resilience and fault tolerance.

If a server or worker instance goes offline, another instance can continue to serve traffic. If these instances are distributed among multiple hosts, it can provide even higher levels of resilience and fault tolerance.

PostgreSQL high availability

PostgreSQL provides high availability through replication and clustering.

Refer to the PostgreSQL High Availability, Load Balancing, and Replication documentation for more details.

authentik also has built-in support for PostgreSQL Read Replicas and using PostgreSQL Connection Poolers like PgBouncer or PgPool.

Active-passive authentik deployment

In an active-passive deployment, one authentik instance actively serves all requests while the other is on standby, prepared to assume control in the event of a failure.

The components of an active-passive authentik deployment include:

• Active Instance: Handles all user authentication requests, API calls, and background tasks. It is fully operational and serves live traffic.
• Passive Instance: Runs as a hot/warm standby. Does not handle incoming traffic or processing. Does not actively write to the database.
• Shared Database: Both instances connect to the same PostgreSQL database which ensures data consistency. Because authentik is stateless, there are no data conflicts.
• Load Balancer: A load balancer monitors the active instance's health. Upon detecting failure, it promotes the passive instance to active by redirecting all traffic to it. This failover can be triggered automatically or manually, depending on your failover strategy. When the original active authentik instance is restored, it can either remain passive or be promoted back to active (failback).

For more information on monitoring the health of an authentik instance, refer to the Monitoring documentation.

The following diagram shows a typical active-passive configuration:

graph TD
    subgraph authentikInstances["authentik instances"]
        A[Active authentik instance]@{stroke: #fd4b2d}
        P[Passive authentik instance]@{stroke: #fd4b2d}
    end

    U[Users]@{ shape: processes}
    L[Load Balancer]
    PG[(PostgreSQL Cluster)]

    U <-->|Traffic| L

    L <-->|Traffic + Health monitoring| A
    L ---|Health monitoring| P

    A <-->|Database traffic - Read and Write| PG
    P ---|Database traffic - Read only| PG

    style A stroke: #fd4b2d,stroke-width:2px
    style P stroke: #fd4b2d,stroke-width:2px
    style authentikInstances stroke:#fd4b2d,stroke-width:2px

This setup provides several advantages:

• Resilient hosting options: The ability to host each authentik deployment in separate environments. Different hardware, datacenters, or providers can be utilized for each deployment to increase resiliency and fault tolerance.
• Continuity of service: During maintenance windows, continuity of service can be assured by switching between active and passive instances.
• Automatic failover: A load balancer allows for automatic failover based on health monitoring, rather than waiting for administrators to detect an issue and manually failover.
• Possibility of blue-green deployment: The use of a load balancer also allows for blue-green methodology, assuming that appropriate changes are made to the database.