Why authentik outpost upgrades need their own plan
Every authentik core upgrade includes an outpost step, because the authentik server and all outposts must run the same version. If you run LDAP, RADIUS, proxy or RAC outposts, treat them as part of the upgrade scope from the start, not as a follow-up task after the core is back online. A core that has moved ahead of its outposts leaves LDAP, RADIUS, proxy or RAC clients depending on an outpost that no longer matches the server they talk to.
The supported path is sequential. authentik upgrades move one release at a time, and you should not skip versions. Work through the upgrade documentation in order, and apply the outpost step at each release you pass through, not only at the final target. The version-specific breaking changes for the core are covered in the sibling upgrade pages, so this section does not repeat them. Confirm the exact sequence and any stop points for your current version in the authentik upgrade documentation before you schedule work.
Before the change window, inventory every outpost and record how it was deployed. Outposts created through the Docker or Kubernetes integrations upgrade automatically, while manually deployed outposts need their image tag updated by hand. Decide who owns each manual update and how you will confirm the new version on each outpost before clients are routed through it. Plan the order so that no client depends on an outpost that is out of step with the core for longer than your change window allows.
What changes for outposts in each release
This table compares the outpost rules that hold across authentik releases and shows what each one asks of you. Read it before choosing a target version, then check the release notes for the specific outpost changes in that version.
| Change | Impact | Action needed |
|---|---|---|
| Server and outposts share one version | Outposts on a different version from the core can fail to match the server, and the admin interface flags them as outdated. | Plan the outpost upgrade in the same change window as the core upgrade, and confirm the version of every outpost before you close the change. |
| Outposts from Docker or Kubernetes integrations | These outposts upgrade automatically when the core is upgraded through the integration. | Confirm the integration is connected and healthy after the core upgrade, then check the Health and Version column. |
| Manually deployed outposts | These keep the image tag you set. They do not change until you update the tag, so they can fall behind the core. | Update the image tag to the new authentik version on every manually deployed outpost, and restart each one. |
| Outdated outposts shown in the admin interface | A red warning appears in the Health and Version column under Applications > Outposts. | Treat any red warning as a blocking item for the upgrade and resolve it before users rely on the affected outpost. |
| Redis removed in 2025.10 | Outposts connected to a deployment that moved caching, tasks, sessions and WebSocket functions to PostgreSQL depend on the new database layout. | Confirm PostgreSQL connection capacity and TLS settings before upgrading, and verify outpost connectivity after the core restarts. |
| Connection count after 2025.10 | The 2025.10 release notes warn of roughly 50% more PostgreSQL connections after upgrading, which affects every component that connects to the database. | Size PostgreSQL for the higher connection count, and review the 2025.10 release notes for the exact figures and guidance. |
| Release-specific outpost changes | Other releases can change outpost behavior, configuration or image requirements beyond the rules above. | Read the release notes for your target version and confirm each outpost change with the vendor before scheduling the upgrade. |
Upgrading outposts after the core upgrade
This sequence keeps every outpost on the same version as the authentik core, so LDAP, RADIUS, proxy and RAC clients keep working after the upgrade. Each stage ends with a check you can confirm before moving on.
Confirm the target version and supported release line
Before touching any container, record the authentik version you are moving to and confirm it sits on a release line listed as supported in the security policy. Check the current release on the GitHub releases page, and read the upgrade notes for every version between your current release and the target. Your platform team owns this step, and it is done when the target version and the upgrade notes are written into the change record. Confirm the rollback point now: a verified backup of the PostgreSQL database taken before the upgrade starts. Restoring from that backup is the preferred recovery path, not a downgrade of the running image.
Upgrade the core server and worker
Update the server and worker containers to the target version, following the authentik upgrade documentation for your deployment method. The server runs core with an embedded outpost, and the worker handles background tasks, so both must move to the same tag. Let the database migrations finish before you consider the step complete. The check is that the admin interface loads, you can sign in as an administrator, and the server and worker logs show no migration errors. If migrations fail, stop here and restore the backup taken in the previous step.
Check outpost health and version in the admin interface
Sign in to the admin interface and open Applications > Outposts. Review the Health and Version column for every outpost. Outposts still on the old version display a red warning, so this view shows you exactly which outposts need action. Record the list of outposts that are current, those that are outdated, and those that report no health. This is your baseline for the next steps. Do not change any outpost yet, because the integration-managed and manually deployed outposts follow different paths.
Let integration-managed outposts upgrade automatically
Outposts deployed through the Docker or Kubernetes integrations upgrade on their own after the core is on the new version. Wait for the reconciliation to finish, then return to Applications > Outposts and confirm each integration-managed outpost now shows the target version and a healthy status. If one remains outdated after a reasonable wait, check the container or pod logs for that outpost and confirm the integration can reach the core. Do not edit these outposts by hand unless the integration cannot complete the update, because manual changes can conflict with automatic management.
Update image tags on manually deployed outposts
For each outpost you deploy yourself, set its container image tag to the same version as the core, then restart or redeploy that outpost. Your team owns the deployment manifests or Compose files, so change the tag in version control and apply it through your normal change process. Keep the previous image tag recorded so you can revert the single outpost if it fails to connect. The step is done when the redeployed container starts cleanly and appears in the admin interface on the target version. Confirm the outpost token and the core URL are unchanged, since a changed token will show as a disconnected outpost.
Re-check health and version across all outposts
Return to Applications > Outposts and review the Health and Version column again. Every outpost should show the target version with no red warning. Compare the result with the baseline you recorded earlier, and confirm that no outpost has dropped out of the list. If an outpost still shows outdated or unhealthy, do not proceed to client testing. Fix the outpost first, or roll that single outpost back to its recorded previous tag while you investigate. Note that rolling back an outpost is a containment step, and it should not be treated as a full authentik downgrade.
Test each protocol client after the upgrade
Test one representative sign-in path for each protocol the outposts serve. For LDAP, run a bind and a search from a test client against the LDAP outpost. For RADIUS, send a test authentication request. For proxy outposts, sign in to a protected application through the reverse proxy. For RAC, open a remote session. Record the result for each path, including the account used and the time of the test. Your application owners should sign off on their own applications, because only they know the expected behavior. The sequence is complete when every tested path works and the results are filed with the change record. If a path fails, use the backup as the recovery point rather than downgrading the running stack.
Automatic or manual outpost upgrades by deployment method
Outposts deployed through the Docker integration upgrade automatically when the authentik server moves to a new version. The integration pulls the matching outpost image and replaces the running container, so your team's work is mostly verification. The upgrade only happens if the integration is connected and the host can complete the pull, so confirm the outcome before you assume it worked.
- Upgrade the server first: Finish the core upgrade before judging the outpost, because the outpost follows the server version.
- Watch host connectivity: A broken connection between the server and the Docker host, or a failed image pull, leaves the outpost on its previous version.
- Confirm in the admin interface: Open Applications > Outposts and check the Health and Version column for each outpost.
- Find hand-deployed outposts: Containers started outside the integration on the same host are not covered and need the manual steps described in another tab.
Before you close the change, confirm that every outpost shows a version that matches the server and no red warning in the Health and Version column.
Outposts deployed through the Kubernetes integration also upgrade automatically when the authentik server is upgraded. The integration updates the outpost workload to the matching version, and Kubernetes then performs a rollout. Drift in this model usually comes from the rollout not completing or from configuration outside the integration that holds an older image reference, so the check focuses on the workload and the admin interface together.
- Upgrade the server first: Complete the core upgrade so the integration has a new target version to apply.
- Watch the rollout: Check that the outpost pods replace the old ones and become ready. Pods that fail to start or fail health checks keep the previous version running.
- Review pinned image references: Confirm whether any manifest, Helm values file or GitOps repository pins an outpost image tag, since a pinned tag can conflict with the automatic update.
- Confirm in the admin interface: Open Applications > Outposts and check the Health and Version column for each outpost after the rollout finishes.
Before you close the change, confirm that the rollout completed in the cluster, that no outpost shows a red warning, and that the reported version matches the server.
Outposts deployed manually are not upgraded by authentik. Your team owns the container or workload definition, so the outpost stays on whatever image tag it was started with until someone changes it. This is the most common source of version drift after a core upgrade, because nothing in the platform forces the change. The upgrade is a deliberate step that updates the image tag to the version of the server.
- Inventory every manual outpost: List each outpost that the integrations do not manage, including its host, workload name and current image tag.
- Update the image tag: Change the tag to the same version as the core server in the same change window, then recreate or restart the outpost so it runs the new image.
- Verify the connection: Confirm that the outpost reconnects to the server after the restart and that the services it serves still authenticate users.
- Confirm in the admin interface: Open Applications > Outposts and check the Health and Version column. A red warning means the outpost is still outdated or unhealthy.
Before you close the change, confirm that every manual outpost appears in the admin interface with a matching version and without a warning.
Preparation before touching outposts
Outposts are the part of an authentik upgrade that clients notice first, because LDAP and RADIUS users authenticate against them directly. The cards below cover the work to finish before any outpost image changes, so a failed step can be rolled back without guessing what was running.
Back up the database before the core upgrade
authentik stores all configuration and data in PostgreSQL, except uploaded files, so a database backup is the rollback point for the core and every outpost that depends on it. Take the backup while the stack is quiet and confirm it restores into a scratch database. Record the authentik version it was taken from, because outposts must return to that same version if you roll back.
Inventory every outpost and protocol
List each outpost under Applications > Outposts with its type: LDAP, RADIUS, proxy or RAC. Note where each one runs, whether it was deployed through the Docker or Kubernetes integration or manually, and which applications or directories depend on it. This list tells you which outposts upgrade automatically and which need your attention.
Collect every image tag in deployment files
Search your Compose files, Helm values, manifests and CI pipelines for every authentik image reference, including outposts deployed by hand. A tag left at an old version is the most common reason an outpost stays behind the core. Write down each file path and the tag it pins so the update list is complete before the change starts.
Stage outposts that mirror production
Run a staging copy of the core with outposts of the same types, protocols and provider configuration as production. Upgrade it first and watch the Health and Version column until every outpost reports the new version. Staging will not catch every client-side issue, but it shows whether outposts reconnect to the core after the upgrade.
Write a client test list for LDAP and RADIUS
LDAP and RADIUS clients such as Wi-Fi controllers, VPN concentrators, Linux hosts and network devices often hold their own bind accounts and shared secrets. Prepare a short list of test logins for each client type: a standard user, a user with MFA, a user in a restricted group and a service bind. Run the list on staging and again after production, and record the results.
Agree a change window with application owners
Outpost restarts interrupt sign-in for every application behind that outpost, so the window must be agreed with the owners of those applications, not only with the platform team. Confirm who can approve a rollback, who monitors sign-in after the change and how users are told about any interruption. Put the agreed window and contacts in writing before the change starts.
Reading outpost health and version in the admin interface
Open Applications > Outposts in the authentik admin interface to see every outpost your server knows about, with a Health and Version column that shows whether each one is running. An outpost that is behind the core shows a red warning in that column. Treat the warning as a required change, not a cosmetic one: the server and all outposts must run the same version, so a red entry means at least one protocol endpoint (LDAP, RADIUS, proxy or RAC) is serving requests from older code than the core expects. Find the matching release on the authentik upgrade documentation, then update the outpost by the route that matches how it was deployed. Outposts created through the Docker or Kubernetes integrations update themselves, so a red warning on one of them usually points to a stalled integration or a connectivity problem rather than a missing step. Outposts deployed by hand need their image tag changed to the core's version, and the warning should clear once the outpost reconnects.
A green status does not prove that each client still works. The column reports that an outpost is connected and reporting a matching version, but it does not test a bind, a RADIUS access request, a forward-auth redirect or an RAC session against a real account. After each upgrade, run a short protocol-level check for every outpost type you use: an LDAP bind and search with a test service account, a RADIUS authentication with a test user and the shared secret, a forward-auth login to a protected test hostname, and an RAC connection to a non-production target. Record the expected results before the upgrade so the comparison is straightforward. Confirm with your own configuration which checks apply, since client software and network paths differ between sites.
Plan for the window between the core upgrade and the last outpost upgrade. Clients may reach a core that expects a newer outpost version, so schedule outpost updates in the same change window as the core and keep a rollback path that includes the previous outpost image tags. Check the Health and Version column again after the change, and keep the result, the time and the test outcomes in your change record so auditors and on-call staff can see when each outpost moved.
How much effort and outside help do outpost upgrades need?
How long does an authentik outpost upgrade take?
The duration depends less on the outpost itself than on how many outposts you run, how they are deployed, and how much testing your environment needs before a change goes live. An outpost on the Docker or Kubernetes integration typically follows the core version without manual steps, so the main time is verification. Manually deployed outposts add work because each image tag must be changed, restarted and checked. Ask any partner to state the number and type of outposts in scope, the test environments available, and the change window they need before giving a timeline.
Can an in-house team upgrade authentik outposts without a partner?
Yes, for most teams with container or Kubernetes experience, because the work is a version match and a health check. The authentik documentation states that the server and all outposts must run the same version, and it shows outdated outposts with a red warning in the Health and Version column under Applications > Outposts. Your team needs access to the admin interface, the deployment tooling for each outpost, and a rollback plan. Outside help becomes more useful when outposts span several networks, when LDAP or RADIUS clients are business-critical, or when staff capacity is limited during a core upgrade.
What does a partner need from my team to scope an outpost upgrade?
A partner needs an accurate inventory before it can scope the work. Provide the authentik version of the core, a list of every outpost with its type (LDAP, RADIUS, proxy or RAC), how each is deployed (Docker, Kubernetes or manual), where it runs, and which applications or clients depend on it. Also provide your change approval process, your test environment, backup and restore arrangements, and the names of people who can approve maintenance windows. Gaps in this inventory are the most common reason a fixed-scope quote changes after work starts.
What does a fixed-scope quote for outpost upgrades cover?
A fixed-scope quote covers the outposts, environments and activities named in a written scope, along with the deliverables and timeline agreed before work starts. Ask that it state which outposts are included, whether test and production are both covered, how the upgrade is verified against the admin interface health and version view, whether rollback steps are documented, and what handover material you receive. It should also state what is excluded, such as core upgrades, changes to the underlying platform, or troubleshooting of client applications. Fees and effort are set by that written scope, and DeployOpen does not publish a price list.
Can outposts run a different version from the authentik core?
The authentik documentation says the server and all outposts must run the same version, so a lagging outpost should be treated as an open issue rather than a supported state. An outdated outpost is flagged in the admin interface, and it may not behave correctly with the core after the core moves forward. Plan outpost upgrades in the same change window as the core upgrade, and confirm the exact compatibility requirements for your target version against the release notes before scheduling. Do not defer outpost work to a later maintenance cycle without a documented reason and a date.
What happens if an authentik outpost is left on an old version?
An outpost left on an older version is out of step with the core, and the admin interface shows a red warning in its Health and Version column. The consequences depend on which protocol it serves. A proxy outpost in front of applications, or an LDAP or RADIUS outpost used by network clients, may fail in ways that look like user or application faults, which makes troubleshooting slower. Security fixes are only delivered to supported versions listed in the authentik security policy, so confirm that your core and outposts sit on a supported line. Ask your partner to include a version check in your routine operations.
Do outpost upgrades carry ongoing costs after the first upgrade?
Yes, the recurring cost comes from keeping outposts aligned with each core release, not from the upgrade itself. Each authentik release that you adopt requires a version match across the core and every outpost, along with a health check afterward. Teams that run Docker or Kubernetes integrations may see less per-release work, while manual outposts repeat the image tag change each time. Ask a partner whether an ongoing support or upgrade retainer covers future outpost releases and whether the written scope includes them.
What makes outpost upgrades longer or shorter
This table compares the factors that change how much work an outpost upgrade takes, from how many outposts you run to how far behind the core you are. Use the third column as a checklist before you schedule the change window, because most surprises come from deployment method and custom configuration.
| Driver | Effect on effort | What to check |
|---|---|---|
| Number of outposts | Each outpost is a separate image or container to update, so effort grows with the count and with how many hosts they run on | List every outpost under Applications > Outposts and note its type and host |
| Deployment method | Outposts deployed through the Docker or Kubernetes integrations upgrade automatically, so manual outposts add a tag update and restart for each one | Confirm which outposts were deployed through an integration and which were started by hand with a fixed image tag |
| Protocol clients per outpost | A LDAP or RADIUS outpost serving many clients needs a longer test window, because a failed upgrade stops logins for every dependent service | Count the providers and applications bound to each outpost and list the teams that sign in through them |
| Custom configuration tied to outposts | Custom environment variables, mounted certificates, network rules or reverse proxy settings must be carried into the new version, which adds review and testing | Review compose files, Helm values and any overrides that set outpost variables or mounts |
| Core versions behind | Each skipped core release adds breaking-change review and may require a sequential core upgrade before outposts can match | Check the installed core version and the release notes for each version between it and the target |
| Health and version status | A red warning in the Health and Version column shows which outposts lag, which shortens diagnosis after the core changes | Check the column after each core upgrade and before closing the change window |
Rollback options and their limits
Rolling back an authentik upgrade is narrower than it sounds. The core and every outpost must share one version, so a rollback has to move the core, the outposts and the data back together. The four options below show which parts can be reverted directly and which depend on a restore, and each one should be confirmed against the release notes of the version you are leaving and the version you are targeting.
Restore the database from a verified backup
A restore is the only dependable way back from a core upgrade. authentik keeps its configuration and data in PostgreSQL, apart from uploaded files, so a rollback needs a database dump taken before the upgrade and a copy of the uploaded files from the same point in time. Before you rely on the backup, restore it into a separate environment, start the matching older core, and confirm that a test user can sign in and that outposts reconnect. Record which image tags the backup was taken against, because the restored database and the containers must match each other.
Revert image tags on manual outposts
Reverting a tag only works when the core is reverted to the same version. Outposts deployed by hand run whatever image tag is written in their configuration, so rollback means setting that tag back to the earlier release and restarting each outpost. An outpost on the older tag that connects to a core on the newer version will show as outdated in the admin interface, and it may not work correctly. Change the core and outposts in one planned window, check the Health and Version column afterward, and confirm in the release notes whether the older outpost image can still serve the restored core.
Keep the previous outpost image available
Keep the previous image before you upgrade, not after. Image tags can be overwritten, removed from a registry or left out of a mirror, so a rollback that depends on pulling an older tag may fail at the moment you need it. Record the exact tag and digest of each outpost image in use, copy them into your internal registry or artifact store, and confirm that the nodes can pull them without internet access. Docker and Kubernetes integrations manage outpost images through the core, so for those outposts the version you can return to is set by the core rollback, not by a separate tag you control.
Why core downgrades are not supported
Downgrading the core in place is not a supported rollback plan. Newer releases can change the database layout or stored data in ways an older core may not read, and reverting the container image does not reverse those changes. Treat the core as one-way unless you have a restore ready. Check the release notes of the target version for any statement on backward compatibility, and plan the window around restoring from backup if the upgrade fails. Ask your own team to write down who makes the restore decision and which verification steps must pass before users are sent back to the older version.
How DeployOpen scopes an outpost upgrade
DeployOpen treats the outpost step as a named line item inside a fixed-scope upgrade, agreed in writing before work starts. The written scope lists every outpost in use (LDAP, RADIUS, proxy and RAC, plus any embedded outpost the core runs), the protocols and applications each one serves, the deployment method for each (Docker or Kubernetes integration, or a manually managed image), and the test cases that prove each outpost still authenticates users after the change. Because the server and all outposts must run the same version, the scope also records the target authentik version that the core and every outpost will share, so no outpost is left behind when the core moves.
The scope also fixes the rollback points. For each outpost, the document states the image tag or integration setting in place before the change, who may revert it, and which login paths are checked before and after the switch, such as a bind for LDAP clients, a RADIUS access request from a network device, and a forward-auth session for a protected application. Confirm with your team which of your outposts are updated automatically through an integration and which are updated by hand, because the manual ones are the most likely to drift from the core. Ask that the scope name the owner of the post-change check in the Health and Version column under Applications > Outposts, so the red warning for an outdated outpost has someone responsible for acting on it.
Ongoing upgrades, outpost checks and recurring testing can be covered by a DeployOpen retainer instead of a one-off engagement. Ask for the retainer terms in writing, including which outposts and environments it covers, how version changes are scheduled against the authentik release and security policy, and what is excluded. DeployOpen prepares the systems, test evidence and change records for your own review. Independent auditors and certification bodies, not DeployOpen, decide whether any control is met.
How DeployOpen delivers authentik outpost upgrades
DeployOpen plans and carries out authentik outpost upgrades inside your own infrastructure, keeping each LDAP, RADIUS, proxy and RAC outpost on the same version as the core. The work follows a written scope, a tested build and a handover your team can run without us.
How we scope
- Inventory every outpost, its deployment method and whether it upgrades through a Docker or Kubernetes integration or by hand.
- Record which outposts serve which providers, so each upgrade window names the applications that depend on it.
- Agree in writing which outposts, environments and version targets are in the fixed scope and what is excluded.
How we build
- Update manually deployed outposts by changing the image tag in your deployment files, matched to the core version.
- Confirm the Health and Version column under Applications > Outposts shows no outdated warning after each change.
- Test login, authorization and forward auth paths against each outpost in a non-production environment before the production window.
How we hand over
- Deliver a runbook covering the upgrade order, rollback steps and the health checks to run after each outpost change.
- Document which outposts upgrade automatically and which need a manual image tag update in your environment.
- Walk your platform team through the admin interface checks so they can spot version drift on their own.
How we support
- Ongoing support, upgrades and continuous testing are available as a retainer after the initial handover.
- Retainers can cover the next core release, so outposts are moved to the matching version in the same planned window.
- Ask any provider to confirm response scope and named contacts in writing before the engagement starts.
