Air-gapped Kubernetes deployments: why Zarf wins

Wayne Starr, technical lead of the Zarf team at Defense Unicorns, described the origin problem on the Kubelist Podcast: submarine sailors who know Linux but not Kubernetes need to redeploy clusters when storage fails mid-mission. No Docker Hub. No Helm chart repos. No phone call to DevOps. Zarf is the tool that came out of that constraint, and its solution to the registry bootstrap problem is one of the cleverest things I've seen 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.zst archive
• It bootstraps an in-cluster registry by splitting the registry image into ConfigMap chunks and reassembling them with a Rust binary. 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 (Kessel Run / Platform One lineage), donated to the OpenSSF in June 2024
• Backed by Defense Unicorns ($1B+ valuation, David Petraeus among the investors), which monetizes through UDS, not Zarf licensing

Table of contents

• What an air gap means for Kubernetes
• How Zarf breaks the bootstrap loop
• What happens after init
• From Kessel Run to OpenSSF
• The Defense Unicorns money trail
• What else is out there
• When Zarf is not for you
• Key takeaways

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. Init containers download binaries at runtime.

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, manual docker tag, docker push to a local registry, and custom Helm value overrides for every single chart. No declarative manifest of what's included. No SBOM. No signing. No way to do differential updates. Just a folder full of tarballs and a spreadsheet somebody forgot to update.

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, nuclear facilities, healthcare on isolated clinical networks, and actual submarines that surface every few months to receive software updates via physical media.

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:

1. The ~18MB registry image exceeds the 1MB ConfigMap limit. Zarf splits it into chunks and creates a ConfigMap for each.
2. A statically compiled Rust binary (the injector) is loaded as another ConfigMap.
3. Zarf hijacks an existing pod in the cluster, mounts the ConfigMaps, runs the injector, which reassembles the image chunks and starts a temporary pull-only registry.
4. The permanent docker-registry Helm chart deploys from that temporary registry.
5. The injector tears itself down.

No pre-existing infrastructure. No DaemonSet. Just ConfigMaps and a Rust binary. It works on k3s, RKE2, EKS, AKS, any conformant Kubernetes distribution. The elegance is that it uses only primitives every Kubernetes cluster is guaranteed to have: ConfigMaps and pods.

For edge cases where the standard approach fails (NFTables-based clusters, IPv6-only environments where NodePort injection breaks), there's an alpha proxy mode that uses a DaemonSet running socat over host ports with mTLS. Less elegant, but it covers the corner cases.

What happens after init

Once the in-cluster registry exists, Zarf's workflow has two halves.

On the connected side: zarf package create reads a zarf.yaml and pulls everything your application needs into a compressed .tar.zst archive: container images (OCI format), Helm charts with all sub-chart dependencies, Git repositories (for Flux/ArgoCD-based GitOps workflows, pushed into an embedded Gitea at deploy time), Kustomize overlays (rendered during create), raw manifests, and arbitrary files. Manifests that aren't Helm charts get wrapped into auto-generated charts so Zarf can manage rollback and uninstall uniformly via Helm's Go SDK.

On the disconnected side: transfer the archive across the air gap (USB stick, secure courier, classified data diode, whatever your security policy dictates) and run zarf package deploy. Images upload to the in-cluster registry, charts get applied, Git repos push to Gitea.

The mutating webhook is the other piece that makes this practical. The zarf-agent is a Kubernetes Mutating Admission Webhook that transparently rewrites resource references at deploy time. Pod image paths get redirected to the local registry. Non-pinned tags receive a CRC32 hash suffix (nginx:1.25 becomes nginx:1.25-zarf-298505108) to prevent tag collisions across package versions. Flux GitRepository, OCIRepository, and HelmRepository objects get repointed to the in-cluster Gitea or OCI registry. Same for ArgoCD Application and Repository objects. You deploy upstream Helm charts completely unmodified. No airgap-specific forks. Resources can opt out with a zarf.dev/agent: ignore label.

Two features that deserve specific mention:

Differential packages. Running zarf package create --differential <previous-package> produces an archive that excludes images and Git repos already present in the prior version. When your air gap is a classified courier with a 64GB USB stick, shrinking a 20GB update to 3GB of actual changes matters.

Automatic SBOM generation. Every zarf package create produces a Software Bill of Materials, viewable through a built-in web dashboard. This isn't a nice-to-have. Executive Order 14028 mandates SBOMs for software sold to the U.S. federal government. Zarf bakes it in at the packaging layer, and packages can be signed and verified using cosign before deployment. This is part of why it landed at OpenSSF (supply chain security foundation) rather than CNCF.

From Kessel Run to OpenSSF

The origin story matters because it explains why Zarf works the way it does.

Defense Unicorns was founded in March 2021 by Rob Slaughter (CEO, former Director of Platform One, PhD in Engineering Physics), Jeff McCoy (CTO, 18+ years active-duty Air Force, 551 commits to the Zarf repo), and Andrew Greene. Their lineage runs through Kessel Run, an Air Force software factory in Boston whose roots go back to the Defense Innovation Unit in Silicon Valley circa 2016. They helped build Platform One and Big Bang (the DoD's GitOps reference platform), then spun out to solve the deployment problem they kept hitting: how do you get cloud-native software onto disconnected systems operated by people who are not Kubernetes experts?

The answer was Zarf. And in June 2024, Defense Unicorns donated it to the OpenSSF (Open Source Security Foundation), placing it under the Supply Chain Integrity Working Group. Not CNCF. That's a deliberate choice: Zarf identifies as supply chain security tooling first, Kubernetes tooling second.

The project is healthy. LFX Insights reports activity on 328 of the last 365 days, 39 active contributors per quarter, 346 new PRs per month, and releases roughly every two weeks (v0.76.0 shipped May 14, 2026). Governance runs through a Technical Steering Committee, a ZEP (Zarf Enhancement Proposal) process, bi-weekly community meetings on Tuesdays, and the #zarf / #zarf-dev channels on Kubernetes Slack.

The concentration risk is real, though. Two contributors own 51%+ of commits. One organization (Defense Unicorns) sits above that same threshold. Brandt Keller, a staff engineer at Defense Unicorns and Zarf maintainer, also contributes to the CNCF Security TAG, which is healthy cross-pollination, but the bus factor remains tight for a project that was deliberately donated to a neutral foundation.

The Defense Unicorns money trail

Defense Unicorns raised $136M in January 2026 (Series B, led by Bain Capital), crossing the $1B valuation line. Other investors include Sapphire Ventures, Valor Equity Partners, and David Petraeus (former CIA Director). The company reported 300% year-over-year growth in military systems adoption.

The commercial product is not "Zarf Enterprise." The monetization boundary is clean:

• Zarf (open source, Apache 2.0, donated to OpenSSF): the packaging primitive.
• UDS Core (also open source, Apache 2.0): a hardened Kubernetes platform built on Zarf, using the Pepr policy engine and Lula compliance automation tool.
• UDS Premium (commercial): adds a management UI, real-time observability, and pre-packaged compliance documentation packs for STIG, CMMC, and FedRAMP.

A UDS Package is a Zarf Package that targets UDS Core as its runtime and includes a UDS Package Kubernetes CRD. Pricing is firm-fixed; DoD customers contract through a GSA IDIQ vehicle that accepts task orders from DoD, DHS, and CISA. Under SBIR Phase III authority, it can be sole-sourced.

In June 2025, Defense Unicorns launched the UDS Registry: a curated registry of verified, pre-packaged applications for national security missions. Think of it as an app store for warfighters deploying to submarines, fighter jets, and classified clouds. They also ship UDS Tactical Edge (extending UDS to tactical edge systems) and UDS Army. Stated customers at the service/branch level: U.S. Navy, Army, Air Force, and Space Force.

Spectro Cloud is currently the only third-party vendor integrating Zarf natively at the platform UI level. Beyond that, the commercial ecosystem is Defense Unicorns-centric. No independent consulting firms or alternative managed service providers surfaced in my research.

What else is out there

Hauler from Rancher Government Solutions (a SUSE subsidiary focused on U.S. Government) is the closest open-source alternative. It calls itself the "Airgap Swiss Army Knife" and explicitly avoids being opinionated about deployment workflows. Hauler represents images, charts, and files as OCI Artifacts, stores them in an embedded registry and fileserver, and lets you move them declaratively or ad-hoc. It doesn't bootstrap cluster infrastructure, run mutating webhooks, or manage Helm installs. It has reached v1.0 (stable API); Zarf (v0.76.0, API v1beta1) has not.

If you already have a deployment pipeline and just need a reliable way to transport OCI content across an air gap, Hauler is the simpler tool. If you need end-to-end lifecycle management from packaging through bootstrap through deployment, Zarf is the more complete one.

Replicated solves a different problem entirely: ISVs distributing on-prem Kubernetes applications to enterprise customers. It bundles a K0s-based distribution with the vendor's application as a single installer, including airgap support. The audience is software vendors, not infrastructure operators.

Gravity from Gravitational (now Teleport) used to solve the "cluster as appliance" problem by packaging entire Kubernetes clusters as .tar snapshots. It's discontinued. Community commenters on Hacker News have called Zarf its spiritual successor.

The manual approach (docker save / docker load / skopeo copy / registry scripting) still exists everywhere. It works until you cross ~30 images or need updates more than monthly. Beyond that, the error rates, the missing SBOMs, and the 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. The API schema is still v1beta1. The project's own roadmap says it is "iterating towards a sustainable baseline that can be supported once v1.0.0 is reached" without naming a target date. If you build automation on top of Zarf, budget for tracking upstream closely.

A comparative analysis on rebelion.la called Zarf "a bit complex to use" and "hard to integrate into a pipeline already in place in enterprise projects." That's a fair critique. Zarf is opinionated: you adopt its packaging model, its zarf.yaml descriptor, its init/deploy lifecycle. If your organization already has a battle-tested airgap workflow built on skopeo and custom scripts, retrofitting Zarf onto that is not free.

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.
• Differential packages and automatic SBOM generation make it practical for recurring updates across physical media, with Executive Order 14028 compliance baked in.
• It's an OpenSSF Sandbox project, deliberately placed under Supply Chain Integrity rather than CNCF. The founders' lineage runs through Kessel Run and Platform One.
• Defense Unicorns ($1B+, Petraeus-backed) monetizes through UDS, not Zarf licensing. Apache 2.0 stays intact. The UDS Registry is an app store for warfighters.
• Hauler is the leaner alternative if you only need content transport. Zarf is the choice when you need end-to-end lifecycle management.
• 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.