What the authentik embedded outpost does and when you need it
The authentik embedded outpost is built into the core server container, so it runs whenever authentik runs, and it is not needed by default for most deployments. You need it only when you use proxy providers for forward authentication, because that is the job it serves. If you do not use proxy providers and do not run standalone outposts, the authentik hardening guide advises disabling it to reduce the attack surface of the server.
The server container holds core plus the embedded outpost, alongside the worker container and PostgreSQL. This placement matters for planning: the embedded outpost is not a separate service you can scale or patch on its own, so it follows the server's release cycle and exposure. Before you decide, list every provider in your tenant and note which ones are proxy providers. Also confirm which outpost features your installed version serves, since the set of served features can change between releases. The authentik hardening guide is the right place to check the current recommendation for your version.
Prometheus metrics for the embedded outpost share the core server's metrics endpoint, so disabling the outpost also changes what your monitoring sees from that endpoint. Check your scrape configuration and alert rules before making the change. A practical starting point is an inventory of providers, a check of your reverse proxy routes, and a short test in a non-production instance to confirm that sign-in and application access still work after the outpost is turned off.
Keep, disable or add a standalone outpost: which option fits
This table compares three paths: keep the embedded outpost, disable it, or run a standalone proxy outpost. Read each row by first checking the condition that selects it, then the monitoring change and what you must confirm before you act. The main takeaway is that disabling is only safe after you have confirmed that no proxy provider depends on the embedded outpost.
| Option | Condition that selects it | What changes for monitoring | What to confirm before choosing |
|---|---|---|---|
| Keep the embedded outpost | You have one or more proxy providers that are served by the embedded outpost in the server container | Outpost metrics appear on the core server's Prometheus endpoint, so existing scrape jobs already cover them | Which applications use proxy providers, and that the embedded outpost is the one serving them |
| Disable the embedded outpost | No proxy providers exist and no standalone outposts are planned, as the hardening guide recommends for this case | Remove any scrape or alert rules that expect outpost metrics from the core endpoint, or expect them to go quiet | That no proxy provider, LDAP or RADIUS outpost dependency exists, and that no team plans one for later |
| Run a standalone proxy outpost | Outposts must sit close to applications on a separate network, or you need to scale outpost capacity apart from the core server | Each outpost needs its own monitoring target and health check, separate from the core server | Network paths from the outpost to authentik and to each application, and who owns outpost upgrades and tokens |
| Keep embedded and add standalone | Proxy traffic is growing or a second network zone needs protection while existing proxy providers stay in place | Metrics come from two places, so dashboards must separate core-served and outpost-served traffic | Whether providers can be assigned to a standalone outpost without changing application routing |
Four checks to run before you disable the embedded outpost
Disabling the embedded outpost is only safe if nothing still depends on it. The four checks below cover the traffic path, the outpost connections, the monitoring setup and the version you run, and each one names the evidence to collect before the change goes ahead.
Inventory proxy providers and bound applications
List every provider of type proxy and the applications bound to each one, including the external host, the mode (single application or domain level) and whether it sits behind a reverse proxy or Traefik-style middleware. Export the list from the authentik admin interface or the API so the inventory is a file, not someone's memory. Any proxy provider is a candidate dependency on the embedded outpost. Owner: the identity team, with input from application owners who know which hostnames users actually reach.
Confirm no standalone outpost connects
Check whether any standalone proxy, LDAP, RADIUS or RAC outpost, whether running in Docker or deployed in Kubernetes, is registered to this server and still active. Look at the outpost list in the admin interface, then confirm on each host or cluster that the outpost container or pods are running and reconnecting to this authentik instance. An outpost that is registered but idle still needs review before you decide. Owner: platform engineering, since they run the Docker hosts and Kubernetes clusters.
Check dashboards and alerts for core metrics
For the embedded outpost, Prometheus metrics share the core server's endpoint. Search your Prometheus scrape configs, dashboards and alert rules for jobs or panels that read authentik metrics from the core endpoint. If you disable the outpost, confirm that the metrics you rely on still arrive from the core server, and that no alert fires because a series disappears. Owner: the operations or monitoring team that maintains the dashboards.
Verify version support and the change window
Confirm that the authentik version you run is one that receives security fixes, and plan the change against the release cadence and the advance notice the project gives for security releases. Record the exact running version, check the upgrade notes for your version, and make sure the hardening change is included in a tested change window with a rollback plan. Owner: the platform or security lead who approves production changes.
How to check and disable the embedded outpost safely
This sequence confirms what depends on the embedded outpost, turns it off in a copy first, and proves that proxy-protected applications still send unauthenticated users to login. It ends with a rollback path and a health check on the monitoring endpoint.
Back up the configuration and database
Before any change, the platform owner takes a backup of the authentik PostgreSQL database and records the current deployment files, including the Compose file or Helm values and any environment variables that set outpost behavior. Keep the backup in a location the rollback can reach. The step is done when the team can restore the database into a scratch instance and see the same users, providers and applications, which confirms the backup is usable rather than only present.
Inventory proxy bindings and forward auth routes
Use the authentik admin interface to list every proxy provider, the application it protects and the outpost it is bound to. Then compare that list with the reverse proxy or ingress configuration, noting each forward auth route, auth_request location, forwardAuth middleware or ext_authz rule that calls authentik. Mark any binding that points to the embedded outpost. The output is a written inventory with one row per protected application. If a binding points to a standalone outpost, record it separately because disabling the embedded outpost should not affect it.
Rehearse the change in a non-production copy
The platform team restores the backup into a non-production authentik instance with the same version and proxy configuration, then applies the planned change there. Confirm the exact configuration key for your release in the hardening guide and the outposts documentation, because keys and defaults can change between versions. Do not assume a key from an older guide. The step is done when the copy starts cleanly, the admin interface loads and the protected test application behaves as expected.
Apply the change in production
During an agreed change window, the operator sets the embedded outpost to disabled using the configuration key confirmed for the deployed version and restarts the server container so the change takes effect. Record the time, the operator and the exact diff from the configuration files. The step is done when the server reports healthy after restart and the logs show no errors about missing outposts or unresolved bindings. Any proxy binding that still references the embedded outpost will surface here, so resolve those before moving on.
Verify redirects and rejections for protected routes
From a clean browser session with no cookies, open each protected application from the inventory and confirm the request redirects to the authentik login page. Then send an unauthenticated request to a protected route with curl and confirm the response is a redirect or a 401 or 403 from the proxy path, never the application content. Sign in and confirm access is granted. The step is done when every inventory row passes both checks. Any application that loads without a login has an unprotected route and the change should be rolled back until it is fixed.
Check the monitoring endpoint after the change
Because Prometheus metrics for the embedded outpost are served from the core server's endpoint, confirm that the metrics endpoint still responds after the change and that the scrape target in Prometheus is reported as up. Compare metric names and counts with the values captured before the change. A missing family of outpost metrics is expected if the outpost is disabled, but the core server metrics should remain. Record the result in the change log and update any alert rules that referenced outpost-specific series.
Roll back if any check fails
If a redirect check, rejection check or health check fails, the operator reverts the configuration key or restores the deployment files from the backup, restarts the server container and repeats the verification in the previous step. Keep the failed diff for review. The step is done when the protected applications pass the same checks they passed before the change. Only then should the team investigate the cause in the non-production copy and schedule a new attempt.
Record the state and schedule a review
Update the deployment documentation with the final configuration, the verified proxy bindings and the monitoring results. Note the authentik version in use and the date of the change so future upgrades can check the hardening guide against the current release. Plan a review at each version upgrade, since the embedded outpost behavior and configuration keys may change, and confirm the exact key again before applying it elsewhere. The step is done when the runbook reflects the live state and a named owner has accepted it.
What changes for metrics and monitoring
Disabling the embedded outpost can change what your monitoring shows, because its Prometheus metrics are served from the same endpoint as the core server. A team that scrapes that endpoint may see outpost-related series disappear or change shape once the outpost is off, even though the core server keeps running. Treat the change as a monitoring change as well as a configuration change, and find out before you touch the setting which series your version actually exposes.
Start with an inventory. Check which scrape jobs point at the authentik server, which dashboards query those series, and which alert rules depend on them. Confirm the metric names your authentik version exposes by querying the endpoint directly and listing the outpost-related series, since names can differ between releases and should not be assumed from older documentation. Read the authentik outposts documentation for the current description of what the embedded outpost reports. Then decide whether any alert depends on an outpost series. An alert that fires on a missing series can look like an outage after the change when nothing is wrong.
Before the change, record baseline dashboards for a representative period, then make the change in a test environment and compare the same panels afterward. Note which panels go empty, which keep their values, and whether any series moved to a different label set. Update scrape configuration and alert rules in the same change window, and add a short note to the runbook so on-call engineers know the expected gap. If you later run a standalone proxy outpost, confirm that it exposes its own metrics endpoint and add a scrape target for it before relying on those signals.
How the decision differs on Docker Compose and Kubernetes
In a Compose deployment, the authentik server container runs the core application with the embedded outpost, and a separate worker container runs background tasks. Both sit beside PostgreSQL in one project on one host, so the embedded outpost is reached through the ports the server container publishes. Standalone proxy outposts usually run as additional containers on the Docker hosts where your protected applications already run, joined to the same application network and registered with an outpost token. The Docker Compose installation guide positions Compose for test setups and small-scale production.
- Published ports: Check which host ports the server service publishes and whether they bind to localhost or to a public interface. Your reverse proxy depends on those bindings.
- Proxy routes: If your reverse proxy sends outpost paths to the server container, the embedded outpost is already on the request path. Disabling it without changing those routes will break them.
- Standalone outposts: Plan one per Docker host that needs one, connected to authentik over the network with its own outpost token and kept on the application network.
- Host sizing: The guide calls for at least 2 CPU cores and 2 GB of RAM, so any extra outpost container should fit within that budget.
- Metrics scraping: Embedded outpost metrics share the core server endpoint, so your scrape job should target the server container.
Before changing anything, review every service in the Compose file that uses the authentik image, each published port and every proxy label or upstream that points at the server container, then test the change in a staging stack.
With the Helm chart, server pods run the core process and the embedded outpost, while worker pods handle background tasks and PostgreSQL is supplied separately. The embedded outpost is reachable through the service and ingress that the chart creates for the server, so its exposure depends on the ingress rules you configure. Standalone outposts usually run as separate workloads in the cluster, often in the namespace of the applications they protect. You can deploy them with your own manifests or use the Kubernetes integration described in the outposts documentation. The Kubernetes installation guide installs with Helm.
- Service and ingress: Review the server service and ingress values to see which hostnames and paths reach the embedded outpost, and whether any path rule sends proxy traffic to it.
- Bundled PostgreSQL: The guide says the bundled database is for demonstration and test environments and recommends a separately managed PostgreSQL for production. Confirm the database values point to that service.
- Replica counts: Confirm server and worker replica counts in your values file, since outpost configuration changes affect every server pod.
- Outpost placement: Decide which namespace and ingress each standalone outpost uses, and confirm its service account and token secret exist before you remove the embedded outpost.
- Metrics scraping: Embedded outpost metrics share the core server endpoint, so confirm your ServiceMonitor or scrape configuration targets the server service.
Before changing anything, find the outpost setting in the chart values reference for your chart version, roll the change out in a non-production release and confirm that every proxy route still responds.
Why the hardening choice has to survive every upgrade
The embedded outpost decision is not a one-time setting. A deployment that disables the embedded outpost today can find itself with a proxy provider tomorrow, and a deployment that left it enabled can keep carrying an unused listener through several upgrades. Each new release can change how the server, the worker and any outposts behave, so the question "do we still need the embedded outpost?" has to be answered again at every upgrade, not only at install time. Treat the hardening guidance as a condition to re-check, not a box ticked during the first build.
The authentik security policy lists the versions currently receiving security fixes and states that security releases are announced at least 24 hours in advance. That short notice window means an emergency patch can arrive when the team has no upgrade planned. Confirm which version lines your deployment runs, and whether it is on one of the supported lines, before a security notice arrives. Then decide in advance who reads release notes for each candidate version, and who checks the outpost settings against the list of proxy providers still in use. Record the answer in the same change record as the upgrade, so the hardening decision is reviewed alongside the version it depends on.
Plan this check as a standing step in your upgrade cadence. For each upgrade, confirm three things: which proxy providers are configured and bound to the embedded outpost, whether any standalone outpost has replaced them, and whether the release notes mention changes to outposts or the server image. If the proxy provider count has dropped to zero and no standalone outpost is in use, disabling the embedded outpost is the next step in the hardening guidance. If the count has grown, confirm that the team still wants proxy traffic served by the core server rather than a separate outpost. Run the check in a staging environment first, because the consequences of a wrong call show up as broken forward auth on live applications.
Limits to confirm in your environment before you change anything
Disabling the embedded outpost changes what answers requests on your authentik server, so the decision depends on facts about your version, features, monitoring and routing. Confirm each item below in your own environment before you change any configuration.
Confirm your version is supported
Check that the authentik version you run is on the supported list in the security policy before you plan any change. Only versions on that list receive security fixes, and the project announces security releases at least 24 hours in advance. If your version is off the list, plan an upgrade first, because a hardening change on an unsupported release leaves you with no fix path for the outpost code that stays in the server. Record the exact version from your deployment, not the version in your Compose file or Helm values alone.
Confirm no feature depends on it
Review every provider and application you have configured and identify which ones rely on the proxy outpost, including forward auth flows and any header-based applications. Then confirm, for your exact version, whether any other feature you use is served by the embedded outpost rather than a standalone one. Do not assume a provider type works the same way across releases. Test a non-production instance with the setting changed and exercise each protected application before you touch production.
Check enterprise-only features in scope
Identify whether any enterprise-only feature you plan to use, such as the Google Workspace or Microsoft Entra ID integrations, mTLS client certificate authentication, or enhanced audit logging, has a dependency on outpost behavior. Enterprise licensing is defined separately from the MIT-licensed core, so confirm the license terms that apply to the code you run. Ask your authentik contact which enterprise components, if any, interact with the embedded outpost in your version before deciding.
Inventory metrics your monitoring uses
The embedded outpost shares its Prometheus metrics endpoint with the core server. If your dashboards or alert rules scrape outpost-specific series from that endpoint, disabling the outpost can remove them or change their meaning. List every scrape target, dashboard panel and alert rule that references authentik metrics, and compare them against the metrics your version exposes. Confirm the behavior in a staging environment and update alerts before the change reaches production.
Verify routing to the embedded outpost
Trace how your reverse proxy, ingress controller or service mesh sends requests to authentik, including any forward auth paths, auth_request locations or external authorization calls. A proxy or ingress rule that still points at the embedded outpost will fail once the outpost is disabled. Check Kubernetes services, ingress annotations and Compose labels that reference the server container, and confirm which paths, if any, reach the embedded outpost. Test each protected route after the change and keep a rollback path ready.
Questions about the embedded outpost: cost, effort and who should make the change
Can our team review and disable the embedded outpost without outside help?
Yes, in most environments the change is a configuration decision that an authentik administrator can make, but the effort depends on what already depends on the outpost. The main question is whether any proxy provider, forward auth route or standalone outpost still points at the core server. Start by listing every proxy provider in the admin interface and every reverse proxy rule that calls authentik. If the list is empty and you have no standalone outposts, the review is short. If it is long, or the proxy configuration lives in several teams' repositories, the work becomes an inventory and coordination task. A partner is most useful when that inventory is large or when the change has to be tested across several applications at once.
What drives the effort of reviewing the embedded outpost?
The main drivers are the number of proxy providers, the number of applications that sit behind them, and how many systems monitor or call the outpost path. Each proxy provider needs to be traced to an application, a reverse proxy or Kubernetes ingress route, and an owner. Monitoring is a common hidden dependency: if Prometheus scrapes metrics from the core server endpoint, a change to the outpost can affect those dashboards and alerts. Other drivers include how many environments you run (test, staging and production), whether configuration is managed as code, and how well your change history is documented.
Does disabling the embedded outpost lower our cost?
Disabling the outpost does not change the licensing cost, because the open-source edition is free and the enterprise pricing is set by user counts and edition, not by which outposts run. The saving is mainly in reduced attack surface and fewer components to patch and review. Any cost of the change comes from the review, testing and documentation work, which is one-time, plus ongoing checks whenever you add or remove proxy providers. When you request a quote, ask for the review work separately from any later rollout, and ask what regression testing is included for your applications.
How long does it take to verify that the change is safe?
Verification time depends on how many applications are reachable through authentik today and how well each one can be tested after a change. Plan to test sign-in, sign-out, access denial for unauthorized users, and any header-based or session-based behavior for each proxy-protected application. Also confirm that metrics and alerts still work and that no reverse proxy route returns errors. Your own change calendar and release process will set the window. Ask any partner to state the verification steps and the environments used before agreeing on a timeline, and confirm the exact expectations with your authentik version and your reverse proxy vendor.
What happens if we add proxy providers after disabling the outpost?
You will need to re-enable the outpost, or run a standalone proxy outpost, before the new proxy provider can serve traffic. The hardening guide recommends disabling the embedded outpost only when you do not use proxy providers or run standalone outposts, so the decision is tied to your current architecture. Before the change, document how to re-enable it, who approves the change, and what tests run afterward. If you expect to add forward auth soon, a standalone proxy outpost may be the better long-term design, because it lets the outposts be scaled and placed close to the applications they protect.
Which parts of the change should our own engineers keep ownership of?
Keep ownership of decisions that depend on your business context: which applications must remain protected, who approves changes to access paths, and how incidents are escalated. Your engineers also know the reverse proxy and ingress rules best, so they should confirm each route before and after the change. A partner can take on the inventory, the test plan, the configuration change and the written record, if you want that work done in a fixed scope. Agree in writing who signs off on each step, so there is no ambiguity about what is live after the work ends.
Do we need a security or compliance review of the outpost decision?
A documented review is useful for most regulated organizations, because it shows that an unused component was identified, assessed and removed or kept on purpose. The review should record which proxy providers exist, which outposts run, what was tested and who approved the decision. DeployOpen prepares systems, controls and evidence for compliance assessments, but independent auditors and certification bodies issue audit reports and certifications. Ask your auditor which evidence format they expect before the review starts, so that the record matches your control framework.
How DeployOpen works on this
DeployOpen treats the embedded outpost decision as part of the authentik scope, not an afterthought. We inventory which applications need proxy or forward auth, decide whether the server's built-in outpost stays on, and write the result into the engagement plan before any configuration changes are made.
How we scope
- We list every application and whether it uses OIDC, SAML, LDAP, RADIUS or a proxy provider, before deciding on the embedded outpost.
- The written scope states whether the embedded outpost stays enabled, is disabled, or is replaced by standalone outposts, with the reason for each choice.
- Engagements are fixed-scope, so scope, deliverables and timelines are agreed in writing before work starts, and a quote follows from that scope.
How we build
- We confirm the deployed authentik version against the supported release list and plan the change against that version's release notes.
- We verify the outpost configuration in a test environment, checking that disabled proxy routes return errors and enabled routes still authenticate users.
- We check the Prometheus metrics endpoint and alerting rules, so monitoring still works after the embedded outpost changes.
How we hand over
- You receive a written record of the outpost decision, the settings changed, and the test results that confirmed the change.
- The runbook explains how to re-enable the embedded outpost or add a standalone proxy outpost if a new application needs one later.
- Your team receives a walkthrough of the configuration so it can review future changes to providers and outposts without us.
How we support
- Ongoing support, upgrades and continuous testing are available as retainers, so outpost settings can be reviewed at each authentik upgrade.
- We can re-check the outpost decision when new proxy providers are added or when the security posture of the deployment changes.
- Support scope, response expectations and fees are set in the retainer agreement, which we confirm in writing before work begins.
