Running authentik in an air-gapped network: what changes
authentik can run in a network with no internet access, provided you turn off the calls it makes to the outside world and give it every image and asset it needs from inside your boundary. Teams in this position usually operate an isolated segment that still needs single sign-on for administrators, internal applications and operational tools, and they cannot accept a identity service that phones home for update checks or pulls container images at runtime. The documented path is to set a small group of environment variables, mirror the server and outpost images into a registry you control, and deploy outposts by hand where automatic image pulls are not possible.
The three settings to plan for are AUTHENTIK_DISABLE_UPDATE_CHECK, AUTHENTIK_DISABLE_STARTUP_ANALYTICS and AUTHENTIK_ERROR_REPORTING__ENABLED set to false, which stop update checks, startup analytics and error reporting. Avatars also need a decision: setting them to initials avoids requests to external avatar services. Confirm the exact configuration keys and their behavior for your release in the authentik air-gapped documentation before writing them into your deployment, and review the sibling pages on configuration and bootstrapping so these values are applied consistently across every environment.
Enterprise is a separate licensing decision. The open-source code is MIT licensed, and the pricing page lists Enterprise and Enterprise Plus editions with features such as enhanced audit logging and FIPS compliance for FedRAMP requirements. Nothing in the offline setup depends on buying a paid edition, but ask the vendor which support, update and audit features your organization needs in a disconnected environment, since those affect how often you will carry new images across the boundary and how you verify them.
Air-gapped settings and when each one fits
This table compares the four air-gapped settings authentik documents with the choice between managed and manual outpost deployment. Read each row for what the setting stops, what it leaves running, and when it is the right call for your network. The main takeaway is that the telemetry settings are independent of each other, so each one needs its own decision.
| Setting or choice | What it stops | When it fits |
|---|---|---|
| AUTHENTIK_DISABLE_UPDATE_CHECK | The server no longer checks for newer authentik releases from the internet. | Set it on every air-gapped install. Upgrades then come from media you import and verify, on your own schedule. |
| AUTHENTIK_DISABLE_STARTUP_ANALYTICS | Anonymous usage data is no longer sent when the server starts. | Set it whenever the host cannot reach the public internet or your policy forbids outbound usage data. |
| AUTHENTIK_ERROR_REPORTING__ENABLED=false | Error reports are no longer sent to the project's external error tracking. | Keep it off when error details could contain user or network information. Route errors to your internal log pipeline instead if your operators need them. |
| Avatars set to initials | Avatar lookups to external services stop, and users see initials instead of images. | Use it when user photos cannot be fetched from outside the network. Confirm which avatar sources your version still calls. |
| Managed Docker outposts | Nothing is stopped. The server pulls outpost images itself when an outpost is created. | Only works if the Docker host can reach a registry you control and that registry holds the outpost images. |
| Manual outpost deployment | Nothing is stopped. You pull, load and run outpost images yourself. | Fits archive-only transfer across an isolated boundary. Plan an image inventory, version pinning and a repeatable update step. |
How to build an air-gapped authentik install
This sequence takes a network with no internet access from an inventory of required images to a running authentik stack, manually deployed outposts and a verified boundary with no outbound traffic. Each step ends with a check you can record as evidence.
Inventory every image and file the deployment needs
Before anything crosses the boundary, list every container image the install depends on: the ghcr.io/goauthentik/server image used for both the server and worker containers, plus the ldap, proxy, rac and radius outpost images for the outposts you intend to run. Record the exact version tag for each, because the mirror must match the version you deploy. Include the PostgreSQL and reverse proxy images if your design pulls them from the internet too. Confirm each tag against the authentik releases page on GitHub and the air-gapped documentation before you pull anything. Done means you have a signed-off manifest with image names, tags, digests where available, and the owner who approved each item. Keep this manifest, because your change record and any supply chain review will refer back to it.
Mirror the images into an internal registry
On a connected staging host, pull each image from the manifest, verify its digest or checksum against the value your vendor or release page publishes, and then export it as an archive. Carry the archives across the boundary using your approved transfer process, then load them into the internal registry and push them under the same names and tags. Apply the verification step again on the air-gapped side so that the content you deploy matches what you approved. Done means every image in the manifest resolves from the internal registry and a pull test from an isolated host succeeds for each one. Record the checksums in the transfer log, since this is the evidence supply chain controls typically ask for when software crosses an isolated boundary.
Set the offline environment variables
Configure authentik so it does not try to reach the internet. Set AUTHENTIK_DISABLE_UPDATE_CHECK to disable update checks, AUTHENTIK_DISABLE_STARTUP_ANALYTICS to disable startup analytics, and AUTHENTIK_ERROR_REPORTING__ENABLED to false. Set avatars to initials so the system does not fetch remote avatar images. Point image references in your Compose file or Helm values at the internal registry, not at ghcr.io. Keep these settings in version-controlled configuration so they survive redeployment. Done means the configuration file or values set contains each variable, and a diff against your template shows no remaining references to external hosts for images, avatars or telemetry.
Deploy the server, worker and database stack
Start the PostgreSQL database, the authentik server container and the worker container from the internal registry, following the Docker Compose or Kubernetes approach your team has chosen. Generate the secret key and bootstrap credentials inside the isolated network rather than on an internet-connected host, and store them in your approved secrets store. Wait for the containers to report healthy, then sign in to the admin interface through your internal address. Done means both containers are running, the database accepts connections, the admin interface loads over the internal name, and the logs show no failed attempts to reach external hosts. If you see image pull errors or connection timeouts in the logs, return to the mirror step and check the tags before going further.
Deploy outposts manually
Managed Docker outposts pull their images when they are created, which fails without internet access. For archive-only distribution, deploy each outpost (ldap, proxy, rac or radius) yourself, using the internal image reference and the connection token generated in the authentik admin interface, with the same version as the server. Confirm that the outpost version matches the server version exactly, since mismatched versions are a common cause of connection failures. Connect each outpost to the server over the internal network and check its status in the admin interface. Done means each outpost shows as connected with the expected version, and a test authentication flow through each provider completes successfully.
Verify that no outbound traffic occurs
Test the boundary rather than assume it. From the host or network segment running authentik, use your firewall or network monitoring to record outbound connection attempts over a full startup, a login cycle, a flow that sends email through your internal relay, and an outpost connection. Check the container logs for update check, analytics or error reporting messages, and confirm they are absent. Attempt a direct connection to an external host from the segment to confirm the egress block is working. Done means the monitoring record shows no connections to external addresses, the logs show no telemetry activity, and the test results are saved with the date, the software versions and the names of the people who ran them.
Document the baseline and plan updates
Record the final configuration, image digests, outpost versions, admin contacts and the verification results as your baseline. Decide how future releases will enter the boundary, which means repeating the inventory, mirroring, checksum and verification steps for each new version. Ask your authentik contact and the release notes which versions receive security fixes and how much notice the project gives for security releases, then set your update cadence around that. Confirm the upgrade order for the server, worker and outposts before you schedule any change. Done means the baseline document is stored under change control and the update procedure has an owner and a review date.
Security and operational risks of an isolated authentik
An air-gapped authentik install removes the easy paths for updates, telemetry and vendor support, so the risks move into your own processes. The cards below cover what crosses the boundary, how you keep security releases current, how outpost secrets are handled and how you see failures without external error reporting.
Verify every image before it crosses
Every server, worker and outpost image you carry into the isolated network is code that will run with access to your identity data. Record the digest of each image and archive at the source, check those digests again after transfer, and keep the import log with the change record. The signed-and-verified chain matters more than the file name, since an archive can be renamed or swapped in transit. Confirm with authentik which signatures or digests it publishes for each release before you write the procedure.
Track security releases across the boundary
authentik's security policy lists 2026.5.x and 2026.8.x as the supported versions receiving security fixes, and the project announces security releases at least 24 hours in advance. In an isolated network, that notice only helps if someone is watching the release feed and can move a package across within the window. Assign an owner, define a standing transfer path, and rehearse it so an urgent fix does not wait on a quarterly change cycle.
Handle outpost tokens and keys
Outposts authenticate to the authentik server with tokens, and proxy or LDAP outposts hold key material used to sign and encrypt traffic. Because managed outposts normally pull their images and configuration themselves, a manual deployment means you place these secrets on hosts yourself. Store them in your own secret manager, restrict read access to the outpost hosts, rotate them when staff or hosts change, and confirm the exact token and key handling for your version in the air-gapped guide before you automate it.
Keep server and outpost versions aligned
A manually deployed outpost must run a version that matches the server it connects to. When you move to a new release, the server image and every outpost image move together, and an outpost left behind can fail in ways that look like login problems. Keep an inventory of each outpost host, its image digest and its paired server version. Check the upgrade notes for the target release before any move, and confirm the compatibility rule with authentik for your release.
Monitor without external error reporting
Disabling error reporting with AUTHENTIK_ERROR_REPORTING__ENABLED=false means failures stay inside your environment, which is the intended result. It also means no one outside is notified when a worker queue stalls or a login path breaks. Forward container logs and PostgreSQL metrics to your internal monitoring, alert on worker health and failed logins, and test the alerts with a planned fault. Ask authentik which health and metrics endpoints the release exposes before you build dashboards.
Document the boundary for auditors
Operators of isolated environments often must show how software enters the boundary and who approved it. For critical infrastructure, NERC CIP-013-2 requires supply chain procurement processes to address verification of software integrity and authenticity of vendor software and patches, which is the control behind checking each package carried across an isolated boundary. Keep the transfer procedure, digest records, approval tickets and the patch calendar in one place. DeployOpen prepares this evidence, but independent auditors and regulators decide whether it meets your obligations.
How to verify images before they cross the boundary
The transfer workflow is the control that matters most when authentik images cross into an isolated network. Every server, worker and outpost image you carry across should pass through a defined sequence: pull from a trusted source on a connected system, scan it, verify what the supplier provides, record the decision, and only then import it into your private registry or archive. Write that sequence down as a runbook with a named owner for each step, because the approval record is what an auditor or assessor will ask to see later.
Start with integrity checks. Compare each image digest against the value recorded at pull time, and where the supplier publishes checksums or signatures for the release, verify them before you accept the artifact. Confirm which release you intend to run against the supported versions listed in the authentik security policy, and confirm the exact tags and digests for the server, worker and each outpost image (ldap, proxy, rac, radius) against the authentik releases page. Scan the images with the vulnerability and malware tooling your security team already approves, and keep the scan output with the change record.
The change record ties the workflow together: image names, digests, scan results, verification outcomes, the approver and the date of import. NERC CIP-013-2 asks utilities to address verification of software integrity and authenticity in their supply chain procurement processes, so the record is the evidence that you did this. The requirement applies only if you are a registered entity subject to the standard. If you are not, the same workflow still gives you a defensible answer when your own policy or customers ask how software entered the environment. Confirm your obligations with your compliance lead before you treat the standard as binding.
Limits to confirm in your environment
An air-gapped install is only as isolated as its weakest outbound dependency. The cards below cover the features that still reach external hosts, the release notes that can add new dependencies between versions, and the version match between server and outposts that keeps an offline mirror working.
Features that still call out
Disabling update checks, startup analytics and error reporting does not remove every outbound request. Avatars, map tiles for GeoIP-based views, email delivery and external identity sources such as directories or upstream providers each need a decision. Use a written list of every feature your flows use and test each one from a host with no route to the internet. Confirm the avatar setting you choose, and whether any policy or source depends on a remote lookup.
New dependencies in release notes
Each target version can add an outbound call or a new image that the previous version did not need. Read the release notes for every version between your current install and the target before you mirror anything, and look for new services, new image names or new environment variables. Confirm this against the GitHub releases page for the exact version you plan to run, because a mirror built for an older release can miss a newly required image.
Server and outpost version match
Outposts connect to the authentik server and are expected to run a matching version. Plan the server, worker and each outpost image as one version set, and mirror the same tag for every component. Confirm the compatibility statement in the upgrade notes for your target release, and check that a manually deployed outpost is updated in the same change window as the server it reports to.
Supported version window
Only some release lines receive security fixes, and the project announces security releases in advance. An isolated system still needs a way to bring patches across the boundary, so check which lines are currently supported before you choose a target version. Ask who will review each patch package and how long your team needs to stage it. Plan the transfer schedule around the 24-hour advance notice the project gives for security releases.
Managed outpost image pulls
Managed Docker outposts pull their images when they are created, which fails silently on a host with no registry access. Confirm whether each outpost in your design is managed or deployed by hand, and make sure every image it references exists in your internal registry under the same name and tag. Test outpost creation on an isolated host before go-live, not during an incident.
Supply chain evidence for transfers
Anything carried across an isolated boundary, including container images, Helm charts and blueprints, needs a record of where it came from and how it was checked. Where NERC CIP-013-2 applies, the procurement process must address verification of software integrity and authenticity. Ask your team to record the source, the digest and the approver for each transfer, and confirm with your compliance owner which evidence format they accept.
Questions teams ask before an air-gapped authentik install
What does an air-gapped authentik install cost?
The cost is mostly people time and internal infrastructure, not a license fee for the Open Source edition. Your team or a partner pays for planning, the internal container registry, the image mirroring and verification process, the outpost deployment work, and testing. The one-time work covers building the mirror and the transfer procedure. Recurring costs come from each authentik release: new images must be mirrored, checked and moved across the boundary again. Ask any partner for a quote that splits these items, names the environments in scope, and states which outposts and integrations are included. Nothing in the supplied facts gives a price for this work, so treat any figure you see without a written scope with caution.
Can our own team run an air-gapped authentik install without a partner?
Yes, if you have engineers who already run containers, PostgreSQL and a private registry, and who can work through change control inside an isolated network. authentik documents the required environment variables for disabling update checks, startup analytics and error reporting, and it lists the server, worker and outpost images to mirror. The harder parts are usually the transfer process, the proof that each image is the one you intended to ship, and manual outpost deployment when managed Docker outposts cannot pull images. Decide early whether your team has time to own those steps through every upgrade.
What do we need to provide before the work starts?
Plan to provide the materials an engineer would need to reason about the boundary without internet access. Typical inputs are:
- Network diagrams showing the isolated zones, the transfer path, and where authentik and its outposts will run
- An inventory of every image, package and blueprint that must cross the boundary, including the server and worker images and the ldap, proxy, rac and radius outpost images you plan to use
- Change control rules for approving imports, plus the named approvers and the review steps they expect
- Target versions and the sequence of upgrades you intend to follow
Agree the format and owner of each item in the written scope.
How long does an air-gapped authentik install take?
Duration depends on the environment more than on authentik itself. The main variables are how many outposts you need, whether a private registry already exists, how long your change control and approval cycle takes, and how many environments (test, staging, production) must be built and verified. Any specific number of weeks should come from a written plan based on your environment, not from a general rule. Ask for a timeline that lists each dependency and who controls it.
How do we verify the images we carry across an isolated boundary?
Verify each image and package before it enters the network, and record what you checked. A workable process covers a documented source, a pinned version tag or digest, a checksum or signature check where the publisher provides one, a scan for known vulnerabilities, and a signed transfer record. NERC CIP-013-2 is an example of a control that asks utilities to address verification of software integrity and authenticity in their supply chain procurement processes, and similar expectations appear in other regulated sectors. Confirm with your auditor which evidence they will accept before you design the process.
When does the Enterprise edition matter for an air-gapped deployment?
The Open Source edition covers the air-gapped mechanics described in authentik's documentation. The Enterprise edition matters when you need features that the pricing page lists as Enterprise-only, such as mTLS client certificate authentication, privileged access management, enhanced audit logging, or the Google Workspace and Microsoft Entra ID integrations. Enterprise Plus adds dedicated support with SLAs, multi-instance deployment support and FIPS compliance for FedRAMP requirements. Code in the authentik/enterprise/ directory is under a separate license, so check that license before you ship that code into a closed environment. Confirm current edition terms with authentik before you commit.
What happens to our air-gapped install when authentik releases a security fix?
Each security fix becomes a new mirrored import, a verification step and a planned upgrade in your environment. The authentik security policy lists 2026.5.x and 2026.8.x as the supported versions receiving security fixes, and the project announces security releases at least 24 hours in advance. That notice is short for a boundary that needs approval and transfer, so plan the pipeline for fast imports before you need it. Ask your partner or internal team how the import, test and rollout steps fit inside your change control, and who has authority to approve an emergency import.
What DeployOpen scopes before an isolated build starts
Before any isolated build starts, DeployOpen agrees a written scope with the client, because engagements are fixed-scope and the scope sets the deliverables and timeline. For an air-gapped authentik install, discovery establishes which network zones authentik will sit in, where the server and worker containers and PostgreSQL will run, and which zone each outpost must reach. It also records the internal container registry that will hold mirrored images, the exact authentik version to pin, and the support window the client needs after go-live. Those answers decide almost everything that follows, from how images cross the boundary to who can apply an upgrade.
Discovery also turns the disabled outbound features into concrete settings. The team confirms that AUTHENTIK_DISABLE_UPDATE_CHECK, AUTHENTIK_DISABLE_STARTUP_ANALYTICS and AUTHENTIK_ERROR_REPORTING__ENABLED will be set, and decides whether avatars fall back to initials, as the authentik air-gapped documentation describes. Outpost placement is the other major decision: each outpost is a separate deployment that must be started by hand when managed Docker outposts cannot pull images. Scope should name the outposts (LDAP, proxy, RAC or RADIUS), the hosts that run them, and the approved image list the client's security team has accepted. Ask who owns each image digest and how a changed image is re-checked before it crosses the boundary.
Clients should also be clear about what DeployOpen does not provide. DeployOpen prepares systems, configuration and evidence that support compliance assessments, including any control mapping for transfer procedures or supply chain checks, but it does not issue audit reports, attestations or certifications. Independent auditors and certification bodies make those determinations. The written scope should list the evidence the client expects to hand to its assessor, such as configuration records, image inventories and test results, so that the deliverables match the assessment. Confirm the exact requirement text and control references with your assessor and your own compliance function before the build is scoped.
Who owns which part of the air-gapped build
Security and compliance leads decide what may cross the boundary, who approves it, and what evidence proves the isolated network behaves as intended. For identity, this role owns the decisions about which outbound features are disabled, how software is verified before it is imported, and how remote access to the environment is controlled. Those decisions shape the rest of the build, so they should be made before the platform team pulls a single image.
- Transfer approvals: Define who approves each import of container images, archives and blueprints, and what record is kept for each transfer.
- Telemetry and update settings: Confirm that update checks, startup analytics and error reporting are switched off in the written configuration baseline.
- Integrity checks: Decide how image digests and signatures are verified against vendor release material before images enter the registry.
- Remote access rules: Set the conditions for administrator and vendor access to the identity platform, including multi-factor authentication and session monitoring.
- Evidence: Specify which configuration records, transfer logs and test results an assessor will ask for.
Before approving the build, check that the transfer procedure and configuration baseline match the controls your regulator or framework requires, and confirm those controls with your assessor rather than assuming they are met.
Platform engineers own the mechanics: the internal registry, the mirrored images, the server and worker deployment, the database, and the restore path. They translate the security baseline into working settings and make sure every component starts without reaching the public internet. This role is also where version choices become concrete, because images must match the server release that will run them.
- Registry mirror: Pull the server and worker images along with the ldap, proxy, rac and radius outpost images, then push them to the internal registry under the names your manifests use.
- Environment settings: Set the disable flags for update checks, startup analytics and error reporting, and configure avatars to initials so no external image source is contacted.
- Supported versions: Confirm the target release is on the supported list in the security policy before mirroring, and track the advance notice the project gives for security releases.
- Database and storage: Keep PostgreSQL and any file storage inside the boundary, and document where backups are written.
- Connectivity tests: Start the stack with outbound access blocked and confirm that failures are limited to features you chose to disable.
Before handing off to application owners, confirm the registry tags, digests and environment settings match the approved transfer record.
Application owners deploy outposts and connect the applications users sign in to. Their work depends on the platform team's registry because managed outposts normally pull their own images when created. In an archive-only environment, the application owner must deploy the outpost manually from the mirrored images, and must make sure each outpost points at the correct authentik server and version.
- Outpost deployment: Deploy the required outposts from the internal registry rather than letting the managed Docker outpost pull images from the public registry.
- Version matching: Keep each outpost on the same release line as the server, and record which version runs where.
- Application configuration: Define providers and applications for each internal service, using the approved configuration method for the environment.
- Access testing: Verify sign-in, logout and forward auth for each application with test accounts before users rely on them.
- Change requests: Route any new image or outpost version back through the security approval and registry steps.
Before going live, confirm with the platform team that every outpost and application starts from approved images and that no step silently depends on a public download.
Most air-gapped failures happen at the handoffs, not inside one team. A version approved by security may not match the image the platform team mirrored, and an outpost deployed from a laptop may bypass the registry entirely. Agree on the artifacts that pass between roles, the naming and tagging rules, and who signs off each stage before the build starts.
- Transfer record: Use one record per import that lists the release, image names, digests, the approver and the date of import.
- Naming rules: Agree on registry paths and tags so manifests, outposts and the approved list all refer to the same images.
- Change order: Require security approval before the platform team imports a new release, and platform sign-off before application owners deploy it.
- Shared test plan: Run one connectivity and sign-in test together after every change, so each role can see the same results.
- Ownership of exceptions: Name who decides when a feature needs internet access, and record the risk decision.
Before starting, ask each role to confirm in writing which handoff artifacts it will produce and which it will accept.
How DeployOpen delivers isolated authentik installs
DeployOpen starts every isolated authentik install with a written scope that names the target environment, the components in the build, and the acceptance checks the work must pass. The scope covers the server and worker containers, the PostgreSQL database that holds all authentik configuration and data except uploaded files, the reverse proxy path, any outposts, and the mirrored image set. Because there is no internet route, the scope also defines the offline sources the build pulls from, such as an internal registry or an approved transfer archive. Deliverables and timelines are agreed before work begins, so the client knows what the team will build and what it must provide, such as hosts, a registry, DNS names and certificate authority material.
The build happens inside the client's own infrastructure, whether that is a data center, a cloud account or an air-gapped enclave. DeployOpen configures the update check, startup analytics and error reporting settings on the server and worker, sets avatars to initials, and tests that the platform starts and authenticates users with no outbound connections. Each image and outpost artifact is verified against the client's supply chain procedure before it crosses the boundary, and the outposts are deployed manually from those artifacts. Hardening covers administrator access, secrets handling, TLS, and the trusted proxy configuration, and each setting is recorded in a configuration document that the client's operators and auditors can read without reverse engineering the environment.
Retainer support is optional and is agreed separately from the build. It covers planned upgrades, which for an isolated install means mirroring each new release, checking its release notes and breaking changes, and rehearsing the update before it reaches production. Before a retainer starts, confirm which supported version line your environment will track and how the client will receive security releases, since authentik announces security releases at least 24 hours in advance. Ask for the upgrade and change handling terms in writing, and confirm who pays for hardware, storage and the internal staff time needed to receive each transfer.
