Deploying authentik outposts with Docker

The image source decides what your Docker host must be able to reach before an outpost ever runs. For managed Docker outposts, the outpost controller pulls the outpost image when it creates the container, so the first question is whether the host can pull from the public registry or must pull from an internal one. Authentik documents two settings that control this: container_image_base sets the default image base for outposts, and each outpost's container_image overrides it for that outpost. Check both in the authentik admin interface before the first deployment, and confirm the exact field names and defaults against the authentik outposts documentation, because the setting location can change between releases.

This matters most in air-gapped networks. If the host cannot reach a public registry, you must mirror the outpost image into an internal registry, point container_image_base or the outpost's container_image at that mirror, and make sure the tag you mirror matches the authentik version running in your core deployment. Mirroring the image is a recurring task, not a one-time step: each upgrade of authentik needs a matching outpost image in the mirror before the outpost is updated. The authentik air-gapped documentation describes the approach. Ask your team who owns the mirror, how often it syncs, and how an upgrade is blocked if the image is missing.

Network paths are the second half of the design. The outpost needs a route to the authentik server so it can fetch its configuration and report health, and the host or container needs a route to the protected application so that the proxy can forward authenticated requests. Users must also reach the outpost's listening port through your reverse proxy or load balancer. Map each of these flows on paper, including DNS names, ports and TLS trust for internal certificates, and confirm the required ports and the connection direction against the current authentik documentation for your version. Treat the network layout as something to verify in a test environment before you rely on it in production.

Every Docker outpost must stay on the same authentik version as the server it connects to, so the recurring job starts whenever the server is upgraded. Treat the outpost image as part of the authentik release, not as an independent component. Before each change, read the authentik upgrade guidance for the target version, since it covers the sequential upgrade rule, breaking changes and outpost-specific steps. Then confirm which image each outpost uses: with managed Docker outposts, the controller's container_image_base setting and each outpost's container_image value decide what gets pulled, so an outdated override can keep an outpost on an old tag after the server has moved on.

Track the supported versions on the authentik security policy page. It lists which release lines receive security fixes, and the project announces security releases at least 24 hours in advance. Use that window to schedule the change rather than waiting for an emergency. Subscribe to the authentik releases page so you see new tags as they publish. Note that a release line outside the supported list will not receive fixes, so an outpost left on it carries the same exposure as the server. Confirm the current supported lines with the policy page before you plan each maintenance window, because they change over time.

Test every change on a staging host that runs the same Compose file, the same outpost token type and the same reverse proxy routes as production. Upgrade the server first, confirm the outpost reconnects in the admin interface, then pull and recreate the outpost containers. Recreating containers is what applies a new image, so a plain restart is not enough when the tag has changed. Keep the previous image tag and Compose file in version control so you can roll back the outpost quickly. Check that protected applications still redirect to login and pass identity headers after each step, because a successful container start does not prove that forward auth works.

A written scope is the document that turns an outpost project into something you can budget and verify. For Docker outposts, it should list every Docker host that will run an outpost, each application and the forward auth or proxy provider that protects it, the outpost instances and their token owners, the network paths between the outpost, the authentik server and each application, the image source for every container, and the checks that show the outposts are healthy and enforcing policy. DeployOpen agrees these items with your team before work starts, so the quote follows from the scope rather than from a generic package. Most engagements are fixed-scope, with deliverables and timelines confirmed in writing.

Cost splits into one-time and recurring parts. One-time work covers host preparation, the authentik outpost configuration, Compose or Docker integration setup, network and firewall changes, image mirroring if your registry is internal, test passes against each protected application, and handover documentation. Recurring work covers outpost image upgrades that follow authentik releases, reviewing the supported version lines listed in the authentik security policy, and any retainer you choose for ongoing support. Your own staff are paid for the access approvals, change windows and application owner time that the engagement depends on. Ask the quote to state which of these items it includes and which it assumes you provide.

The main drivers of effort are the number of hosts and applications, whether each application needs its own provider or shares a parent domain, how many network zones the outposts must cross, and whether your environment blocks pulls from public registries. Ask for the scope to name the exact image tags or the internal registry path that each outpost will use, since changing the source later means retesting every container. Before accepting a quote, confirm who owns the outpost tokens after handover, how credentials are rotated, and which verification steps must pass before the scope is considered complete.