Air-gapped Kubernetes is a category that used to be handled by ad-hoc tarballs and a binder full of runbooks. Zarf, originally built for defense and regulated-industry use cases, has matured into the de facto open-source approach for moving Helm-based workloads across an air gap and keeping them maintainable on the disconnected side. The 0.45 release earlier this quarter cleaned up several rough edges and made the tool genuinely usable for non-DoD teams. This walkthrough captures what a competent Zarf deployment looks like in 2026 and the operational realities that documentation tends to gloss over.
The premise of Zarf is that you take everything a Kubernetes workload needs, container images, Helm charts, manifests, scripts, and binary tools, bundle them into a single signed package, ship the package across the air gap by whatever physical means you have, and then deploy it on the disconnected side using a Zarf binary that has no internet dependencies. The model is straightforward; the details are where the work lives.
What is in a Zarf package?
A Zarf package is a tarball with a defined structure: a manifest at the top describing components, a directory of container image layers in OCI format, Helm charts and Kubernetes manifests, any local files the workload needs, and a signature. The package is built on the connected side using zarf package create, which pulls every dependency declared in the package definition and assembles them into the bundle. Image references in the bundled manifests are rewritten to point at the in-cluster registry that Zarf provisions on the disconnected side, so workloads pull from the local registry rather than the public internet.
The package definition, zarf.yaml, is the source of truth for what is in the bundle. It lists images by digest, charts by URL and version, and any custom files or scripts. The discipline of writing a complete zarf.yaml is most of the work of adopting Zarf, because it forces you to enumerate every external dependency your workload has. Teams discover transitive image pulls that were happening implicitly through Helm chart values, and those need to be made explicit in the package definition.
How does the init flow work?
The disconnected-side bootstrap is handled by zarf init, which runs once per cluster and installs the Zarf agent, an in-cluster registry, a Git server for chart hosting, and the mutating webhook that rewrites image and chart references on incoming workloads. The init package itself is a Zarf package shipped alongside the binary, so the bootstrap is self-hosted: you do not need any external pull for the init step.
The init flow is where most first-time deployments stumble. The in-cluster registry needs storage that survives node restarts, which means a real PersistentVolume with adequate capacity for every image you intend to deploy. The Git server has similar requirements. Sizing these correctly up front saves a lot of pain later, because resizing them after the fact requires moving data while the cluster is partially functional. A typical mid-sized deployment runs the Zarf registry on 200 GB of fast storage and the Git server on 20 GB.
What about image and chart updates?
Updates are where Zarf's design philosophy shows. Every update produces a new package on the connected side, gets transported across the air gap by your defined media, and gets applied on the disconnected side with zarf package deploy. The model is deliberately discrete: there is no continuous pull on the disconnected side, no implicit auto-update, no background reconciliation against an upstream. That is the right model for environments where every byte crossing the air gap needs to be reviewed, but it is operationally heavy for teams used to GitOps.
Several teams have layered GitOps tooling on top by running Flux or Argo CD inside the air-gapped cluster, pointing them at the Zarf-provisioned Git server, and using zarf package deploy as the mechanism that updates the contents of that Git server. That hybrid works, gives you continuous reconciliation inside the air gap, and preserves the discrete checkpoint where new bits cross the gap. It is more complex than either pure Zarf or pure GitOps, but for production deployments it is usually the right shape.
How is signing and integrity handled?
Zarf packages are signed with Sigstore Cosign by default. The package signature covers the entire bundle including the manifest, image layers, and charts. Verification happens at zarf package deploy time and can be configured to require a specific signer identity. For workloads that already use keyless signing on their CI builds, this composes cleanly: the underlying images are signed at build time, the Zarf package is signed when assembled, and both signatures can be verified on the disconnected side.
The verification gap to be aware of is that the Rekor inclusion proof for the underlying image signatures is not useful on the disconnected side because there is no Rekor to query. Zarf 0.43 added support for bundling the offline-verification material into the package so that image signatures verify without external dependencies. Make sure your build pipeline produces offline-verifiable signature bundles or this verification step will fail on the disconnected side.
What does the operational story look like?
Operationally, Zarf is heavier than running Helm directly but lighter than the ad-hoc air-gap workflows it replaced. A team running Zarf in production should expect to maintain a package-building pipeline on the connected side, a media-transport process for moving packages across the gap, and a deployment runbook on the disconnected side. The deployment side is mostly automatable but the connected side requires ongoing engineering as your workload definitions evolve.
The thing that surprises teams is the disk usage on the connected side. Building Zarf packages with images and charts means caching all the upstream content, and a multi-cluster, multi-environment package set easily consumes 500 GB or more. Plan for it. The connected-side build infrastructure is genuinely more demanding than a typical CI runner.
How Safeguard Helps
Safeguard supports air-gapped deployments through SBOM-based policy evaluation that runs entirely on the disconnected side once trust roots are established. Zarf packages can carry attached SBOMs that Griffin AI ingests during package build, and the resulting reachability analysis and policy decisions are bundled into the package so they travel across the air gap with the workload. Policy gates evaluate on the disconnected cluster without external network access, blocking deployments that exceed reachable critical CVE thresholds even when the cluster has no connectivity. TPRM scoring of every Zarf-bundled image is computed at build time and shipped as evidence, so supplier risk is auditable on the disconnected side. Our zero-CVE base images integrate with Zarf package definitions out of the box.