The U.S. Navy needed to deploy Kubernetes workloads to submarines that go radio-silent for months. No Docker Hub, no Helm chart repos, no apt-get. That problem produced Zarf, and its solution contains one of the cleverest bootstrap tricks in the Kubernetes ecosystem.
TL;DR
- Zarf is an open-source airgap package manager that bundles container images, Helm charts, and manifests into a single
.tar.zstarchive - It bootstraps an in-cluster registry via ConfigMap injection: no pre-existing infrastructure required
- A mutating webhook rewrites image references so upstream Helm charts work without modification
- Born at the U.S. Department of Defense, donated to the OpenSSF in June 2024
- Backed by Defense Unicorns ($1B+ valuation), which monetizes through UDS, not Zarf licensing
What an air gap means for Kubernetes
Kubernetes assumes the internet exists. The kubelet pulls images from registries. Helm fetches sub-charts from remote hosts. Flux and ArgoCD reconcile against remote Git servers.
Cut all of that off, and your cluster becomes inert. The worst part: you can't deploy a container registry, because you need a registry to pull the registry image. That chicken-and-egg problem is where manual airgap workflows collapse into days of docker save, docker load, and custom Helm value overrides per chart.
Who actually lives with this? Defense and intelligence communities on classified networks at IL4/IL5/IL6+, ICS/SCADA operators on intentionally isolated OT networks, offshore platforms, healthcare on isolated clinical networks, and, yes, actual submarines.
How Zarf breaks the bootstrap loop
ConfigMap injection is the heart of the project. Here's what zarf init does on a fresh, disconnected cluster:
- The ~18MB registry image exceeds the 1MB ConfigMap limit. Zarf splits it into chunks and creates a ConfigMap for each.
- A statically compiled Rust binary (the injector) is loaded as another ConfigMap.
- Zarf hijacks an existing pod, mounts the ConfigMaps, runs the injector, which reassembles the chunks and starts a temporary pull-only registry.
- The permanent
docker-registryHelm chart deploys from that temporary registry. - The injector tears itself down.
No pre-existing infrastructure. No DaemonSet. Just ConfigMaps and a Rust binary, on any conformant Kubernetes distribution.
After init, the workflow is straightforward. On the connected side, zarf package create reads a zarf.yaml and pulls all images, charts, Git repos, and files into a compressed archive. Transfer that archive across the air gap. On the disconnected side, zarf package deploy uploads images to the in-cluster registry and applies charts.
The zarf-agent mutating webhook completes the picture. It rewrites image references in pods, Flux GitRepository objects, and ArgoCD Applications to point at the local registry. You deploy upstream Helm charts as-is. No airgap-specific forks needed.
Not CNCF, but OpenSSF (and that says something)
Zarf is not a CNCF project. Defense Unicorns donated it to the OpenSSF in June 2024, placing it under the Supply Chain Integrity Working Group. That's a deliberate positioning: Zarf identifies as supply chain security tooling, not a general-purpose Kubernetes project.
The project is active. LFX Insights reports activity on 328 of the last 365 days, 39 active contributors per quarter, and releases roughly every two weeks (v0.76.0 shipped May 14, 2026). But the concentration risk is real: two contributors own 51%+ of commits, and Defense Unicorns dominates the contributor graph.
Defense Unicorns raised $136M in January 2026 (Series B, Bain Capital), reaching a $1B+ valuation. Their commercial product isn't "Zarf Enterprise." It's UDS (Unicorn Delivery Service): a hardened Kubernetes platform that uses Zarf as its packaging substrate, adding compliance automation (STIG/CMMC/FedRAMP) and a management UI. Zarf stays Apache 2.0. The boundary between open source and commercial is clean.
What else is out there
Hauler from Rancher Government Solutions is the closest open-source alternative. It's more modest: a content-transport tool that manages OCI artifacts without opinions about deployment. If you already have a pipeline and just need images moved across an air gap, Hauler is simpler. It doesn't bootstrap registries, rewrite image references, or manage Helm installs. It has reached v1.0; Zarf (at v0.76.0, API v1beta1) has not.
Replicated solves a different problem: ISVs distributing on-prem Kubernetes applications to enterprise customers. Different audience, different tool.
The manual approach (docker save / docker load / registry scripting) works until you cross ~30 images or need monthly updates. Beyond that, error rates and labor cost make a dedicated tool inevitable.
When Zarf is not for you
If your clusters have internet access, even through a proxy or artifact mirror, the airgap problem doesn't apply. Zarf adds an in-cluster registry, an embedded Gitea instance, and a mutating webhook. That's overhead you don't want without a genuine air gap.
The pre-v1.0 status matters. Both v0.75.0 and v0.76.0 shipped breaking changes. If you build automation on top of Zarf, budget for tracking upstream closely.
And the Defense Unicorns contributor concentration is worth watching. The OpenSSF donation was the right governance move, but the contributor graph still reads as a single-company project. For environments where decades-long maintenance matters (which is exactly the environments Zarf targets), that factor belongs in your risk assessment.
Key takeaways
- Zarf is the most complete open-source solution for deploying to fully disconnected Kubernetes clusters. The ConfigMap-based registry bootstrap requires no pre-existing infrastructure.
- It's an OpenSSF Sandbox project, deliberately placed under Supply Chain Integrity rather than CNCF.
- Defense Unicorns monetizes through UDS, not Zarf licensing. Apache 2.0 stays intact.
- Pre-v1.0 with active breaking changes. Production-ready for teams that track upstream.
- If your clusters can reach the internet, you don't need it.