Understanding the proxy provider and outposts in Authentik: forward auth, single application, and proxy modes; embedded versus standalone Docker and Kubernetes outposts; the headers sent to applications; and an example outpost deployment with Docker Compose.

The last four episodes built an OIDC bridge for modern applications. But in the real world, many applications don't support OIDC, SAML, or LDAP at all: old tools, simple dashboards, or applications that only accept a plain reverse proxy. Do they have to be left without authentication? No.
In this episode, you'll get to know the proxy provider and outpost — Authentik's way of protecting any application without changing the application's code. To use an analogy: OIDC is like asking every resident of a complex to have their own ID card. A proxy provider is like a single security post at the complex gate — anyone passing through must show their identity there, regardless of who the resident is.
An outpost is a separate component that runs the logic of certain provider types. Some providers — proxy, LDAP, RADIUS, and RAC — don't run inside the Authentik core, but rather in outposts that can be deployed anywhere as long as they can connect to the Authentik API.
The benefits are real:
Outposts come in two main forms:
Here's the comparison:
| Aspect | Embedded | Standalone |
|---|---|---|
| Setup | Automatic, no extra steps | Requires a container or deployment |
| Isolation | Shares core resources | Separate and independent |
| Scalability | Limited | Can be replicated and placed near applications |
| Management | Follows the core lifecycle | Automatic via Docker/Kubernetes integration |
The proxy provider has three modes determining how traffic flows:
Warning
Forward auth in domain-level mode uses one provider for all applications, so the policies bound to that provider apply uniformly. If each application needs different rules, split them into their own single application providers.
Forward auth mode works like a door guard calling an identity verification center. The sequence:
The application never knows how Authentik works — it just reads the headers it's given.
These headers are the bridge between Authentik and the application. The application reads them to recognize who is accessing:
| Header | Contents |
|---|---|
| X-Authentik-Username | The logged-in user's username |
| X-Authentik-Groups | The user's groups, pipe-separated: foo|bar|baz |
| X-Authentik-Email | The user's email address |
| X-Authentik-Name | The user's full name |
| X-Authentik-UID | The user's identity as a hash |
| X-Authentik-Meta-Outpost | The name of the outpost handling the request |
The outpost also provides some additional meta headers, and you can add static headers via the additionalHeaders attribute on users or groups. The outpost listens on port 9000 for HTTP, 9443 for HTTPS, and 9300 for Prometheus metrics.
Outpost management is centered on the Applications > Outposts page in the Admin interface:
Important
An outpost token is a key granting read access to provider configuration. Don't put it in files that go into version control — use environment variables or a secret manager. A leaked token can be used to forge an outpost.
For a standalone outpost, Authentik provides the official proxy image. Example docker-compose.yml:
version: "3.8"
services:
authentik-proxy:
image: ghcr.io/goauthentik/proxy:2026.5.1
container_name: authentik-proxy
environment:
AUTHENTIK_HOST: "https://auth.example.com"
AUTHENTIK_INSECURE: "false"
AUTHENTIK_TOKEN: "token-dari-halaman-outpost"
ports:
- "9000:9000"
- "9300:9300"
restart: unless-stoppedAUTHENTIK_HOST: the Authentik instance address the outpost uses to communicate.AUTHENTIK_TOKEN: the token generated when creating the outpost in the Admin interface.9000 for HTTP traffic, 9300 for metrics.Then run:
docker compose up -dTip
In a production environment, don't hardcode the token in a compose file. Replace the AUTHENTIK_TOKEN value with a host environment variable, for example AUTHENTIK_OUTPOST_TOKEN, so the token is never stored in a shared file.
Key points from this episode:
X-authentik-username and X-authentik-groups become the language applications read.The foundation is complete: you know what an outpost is, how it works, and how to deploy it. In episode 12, it's time to connect this outpost to a real reverse proxy — you'll integrate Traefik with Authentik forward auth, complete with middleware, labels, and header settings so your applications are protected seamlessly.