Air-Gapped Deployment

What Is Air-Gapped Deployment?

Air-gapped deployment is the practice of running software in an environment that has no route to the public internet. Nothing enters or leaves except through a controlled transfer, usually physical media or a tightly governed gateway. Every artifact a workload needs must already be inside the boundary before it runs, because there is nowhere to fetch it from.

Isolated environments are common in classified and defence systems, industrial control networks, and regulated estates where the boundary is itself a control. The gap is maintained deliberately, and treating it as a temporary inconvenience is how teams end up with workloads that cannot start.

The practical consequence is that every assumption about on-demand retrieval has to be inverted. Dependencies are not fetched; they are delivered in advance.

How Air-Gapped Deployment Works

Software reaches an isolated environment through a transfer process rather than a network request. What travels has to be complete, because a missing piece cannot be fetched later:

• The artifact and all its variants — every architecture in a multi-platform image index, not only the one the transferring workstation happens to run.
• Signatures and attestations — stored as separate objects that reference the image by digest; leave them behind and verification fails inside the boundary.
• SBOMs, provenance and VEX documents — the evidence that compliance review and triage depend on, which no scanner can regenerate from an image alone.
• Vulnerability data — scanner feeds go stale within days, so the databases themselves become a recurring transfer, not a one-off.

Transfers are deliberate events. An artifact is staged on the connected side, verified, written to approved media or pushed through a one-way gateway, then re-verified on arrival. The process is auditable by design, which is also what makes it slow.

Why a Pull-Through Cache Cannot Work

A pull-through cache answers a request it has not seen before by fetching from upstream and keeping a copy. The mechanism depends on having somewhere to go on a miss. Inside an isolated environment there is no upstream, so a miss is simply a failure.

The workable pattern is a seeded mirror: a registry populated ahead of time through registry mirroring, holding everything a workload might ask for.

• A miss is fatal, not slow — there is no fallback path, so an unseeded image means a deployment that does not start.
• Completeness is decided in advance — the contents of the mirror are a planning exercise, not something demand fills in over time.
• Index integrity — copying a single platform's manifest leaves a multi-architecture index incomplete and breaks nodes of another architecture.
• Referenced objects travel separately — signatures, attestations and SBOMs are distinct artifacts, and copying the image alone silently removes the ability to verify it.

How to Run Workloads Inside the Boundary in Production Environments

Isolation turns release engineering into logistics, and the logistics reward planning.

• Mirror by digest rather than tag, so what arrives inside is provably the artifact that was approved outside.
• Copy whole image indexes together with their referenced signatures, attestations and SBOMs in one operation.
• Transfer scanner vulnerability databases on their own cadence, and record the feed date alongside every scan result.
• Verify signatures after transfer, inside the boundary, since a check performed on the connected side proves nothing about what arrived.
• Batch releases around the transfer window, and keep a documented expedited path for critical fixes that cannot wait for it.

How Hardened Container Images Reduce the Transfer Burden

Smaller images are cheaper to move. A hardened minimal image carries fewer packages, which means less to transfer, fewer components to account for and a smaller vulnerability surface to triage once the feed arrives.

Echo images are signed and attested and delivered with SBOM, provenance and VEX (echo.ai/product), and are mirrored to Azure, Google Cloud, JFrog, Docker, GitHub, Nexus, Harbor and Red Hat Quay, which gives a staging registry a straightforward place to pull from.

The boundary still sets the cadence. Hardening reduces how much has to cross it.

FAQs

Can a registry mirror replace an air gap?

No. A mirror is a delivery mechanism inside the boundary, not a substitute for it. The gap is a security control; the mirror exists because the gap removes on-demand retrieval. A mirror that quietly retains a route to the public internet is no longer serving an isolated environment at all, whatever the architecture diagram says.

How do vulnerability scanners stay current without connectivity?

Their databases are transferred like any other artifact, on a defined schedule. The practical risk is silent staleness: a scan against a feed that is weeks old returns a clean result that means very little. Recording the feed date with every scan makes the limitation visible to whoever reads the output.

What breaks if signatures are not transferred?

Verification. Signatures and attestations are separate objects that reference an image by digest, so an image copied on its own arrives unverifiable inside the boundary. Admission controllers configured to require a valid signature will then reject it, and the failure usually surfaces at deployment time rather than during the transfer that caused it.

Does an isolated environment still need an SBOM?

Yes, and arguably more than a connected estate does. Isolation removes many remote exploitation paths but changes nothing about the components inside an image. When a vulnerability is disclosed, the SBOM is what answers whether the affected package is present, since there is no external service available inside the boundary to ask.

How often should artifacts be transferred?

Often enough that the environment is not running months-old software, and that depends on how costly each transfer is. Most teams settle on a regular batched cadence for routine updates, plus a separate expedited process for critical fixes, because one schedule cannot serve both kinds of work without being wrong for one of them.