authentik upgrades and support

On a single host, the server container, the worker container and PostgreSQL share one machine, so an upgrade is a short sequence of image changes, a database backup and a restart. The plan is small, but the window is shared: the server and worker restart together, and users cannot sign in until the new containers are healthy. The authentik Docker Compose guide calls for at least 2 CPU cores and 2 GB of RAM and positions Compose for test setups and small-scale production, so confirm the host still has headroom before you change anything.

• Pre-checks: confirm the host meets the guide's minimum of 2 CPU cores and 2 GB of RAM, and check free disk space for a database dump.
• Backup: take a PostgreSQL dump and copy the compose file and environment file before pulling new images.
• Connections: the 2025.10 release notes warn of roughly 50% more PostgreSQL connections after upgrading, so compare the connection limit with current usage.
• Window: agree a maintenance window with users, since sign-in is unavailable during the container restart.
• Verify: after the restart, confirm both containers report healthy, sign in with a test account and check the worker logs for background tasks running.

Before you close the window, confirm that sign-in, one protected application and one background task have all succeeded on the new version.

A Helm deployment separates the release from the database. The authentik Kubernetes guide says the PostgreSQL bundled with the chart is for demonstration and test environments and recommends a separately managed PostgreSQL for production. A production upgrade therefore usually involves a database the client already operates, and the plan covers the chart version, the values file, the database connection settings and the rollout order of server and worker pods.

• Chart and values: pin the chart version and compare the values file with the defaults in the new chart before applying anything.
• Database: confirm the managed PostgreSQL version and connection limit can carry the higher connection count described in the 2025.10 release notes, and note whether a connection pooler sits in front of it.
• Migrations: check the release notes for the target version to see how schema changes are applied, and take a managed database snapshot before the rollout.
• Rollout: check whether the chart's update strategy keeps at least one server pod available during the change.
• Verify: confirm pod readiness, worker logs, sign-in through the ingress and the database connection count after the rollout settles.

The client provides cluster access with a named change owner, the snapshot and retention policy for the managed PostgreSQL, a non-production cluster for rehearsal and the previous chart version as a documented rollback target. Confirm each of these before the window opens.

The further an instance is behind, the more release notes it must read and the more likely it is to meet a breaking change. The 2025.10 Redis removal is the clearest example, because it changes infrastructure as well as configuration: caching, tasks, sessions and WebSocket functions moved to PostgreSQL. The plan starts with an inventory of the running version, followed by a path to the target that is rehearsed one step at a time.

• Inventory: record the running version, the database version, every custom flow, blueprint and provider, and any outpost deployed separately.
• Path: read the release notes for every version between the current and target releases, and confirm with the vendor whether intermediate versions must be installed in sequence.
• Infrastructure: check whether a Redis instance still exists in the deployment that can be retired, and whether PostgreSQL has capacity for the change in connection count.
• Rehearsal: run each step against a masked copy of production data and time a restore of the backup, so the rollback is known in advance.
• Verify: after each step, confirm login flows, provider connections and scheduled tasks still work before moving to the next step.

The client provides a masked copy of production data, access to the current deployment files, named owners for each application that depends on authentik and a decision on the target release line. Confirm the path with the release notes before scheduling the first step.

The authentik security policy lists 2026.5.x and 2026.8.x as the supported versions receiving security fixes. An instance outside those lines is not receiving security fixes, so the first question is how exposed the instance is, and the second is how quickly it can move to a supported line. That move may cross several breaking changes at once. The project announces security releases at least 24 hours in advance, which helps with scheduling but still needs a plan behind it.

• Exposure: document internet reachability, the population that can sign in and whether administrative paths are restricted.
• Target: choose a version within a supported line and confirm the choice against the release notes for every version in between.
• Interim controls: enforce MFA for administrators, restrict admin access to known networks and review recent event logs while the upgrade is planned.
• Breaking changes: map changes between the current version and the target, paying close attention to infrastructure, provider and authentication flow changes.
• Verify: confirm the running version matches the target, and review the security advisories affecting the old version against the new deployment.

The client provides approval for an expedited change window, a named owner who accepts the risk if the upgrade is delayed and a list of applications that depend on authentik. Record the decision and its owner in the change ticket.

In an air-gapped environment, the upgrade depends on what can be moved into the network ahead of the change, and the server cannot fetch anything during the window. Container images, the Helm chart or Compose files and release artifacts must be staged in the client's internal registry and repositories beforehand. Staging is a project of its own, with approvals, transfer controls and integrity checks that run before any production step.

• Images: mirror the server and worker images for the target version into the internal registry, keep the same tag and record the digests.
• Artifacts: stage the chart or Compose files, the release notes and any documentation the team will use during the change.
• References: point every manifest and compose file at the internal registry so no step pulls from a public source.
• Integrity: verify checksums or digests on arrival, and confirm with the project how it publishes them for each release.
• Verify: after the change, confirm no container pulls from an external registry and that the reported version matches the staged tag.

The client provides an internal registry with enough capacity, an approved transfer process for media or one-way data flows, a staging environment that mirrors production and a named signatory for the artifact set. Confirm the transfer approvals early, because they usually set the schedule.