Zarf 1.0: Air-Gapped Kubernetes Delivery Goes Stable

Zarf 1.0 dropped on November 9 at KubeCon 2026 in Salt Lake City — the first stable release of the OpenSSF tool that bundles Kubernetes workloads for deployment in environments with no internet connection. If your team ships software to government networks, hospitals, air-gapped trading systems, or Defense Department infrastructure (the tool literally runs on Navy submarines), the upgrade path matters. Here is what changed and what will break.

What Zarf Does, in One Paragraph

Zarf solves a specific, nasty problem: getting a Kubernetes workload running in a network that has no outbound internet access. It bundles container images, Helm charts, manifests, and scripts into a single signed tarball on the connected side, ships that tarball across the air gap by whatever physical means you have, then deploys it on the disconnected cluster using a Zarf binary that needs no external dependencies. A mutating webhook (the zarf-agent) rewrites image references on the fly so your workload points at the internal registry instead of Docker Hub or ECR. The result: repeatable, verifiable, offline-first deployments without maintaining a parallel set of air-gapped Helm values.

The Breaking Change You Will Hit

The biggest practical change in 1.0 is the shift from variables to values in the new v1beta1 package schema. If you use --set-variables or ###ZARF_VAR_*### templates today, they will throw an error on v1beta1 packages — not a warning, an error. The fix is straightforward, but every pipeline that sets configuration at deploy time needs to be updated.

The old pattern:

zarf package deploy my-app.tar.zst --set-variables DATABASE_URL=postgres://prod:5432/db

The new pattern:

zarf package deploy my-app.tar.zst --set-values database.url=postgres://prod:5432/db

Values support nested Go templating ({{ .Values.database.url }}), which is a genuine improvement over the flat ###ZARF_VAR_### syntax. The migration is not complex, but it is mandatory. Zarf 1.0 ships tooling to convert existing packages automatically, and the official migration guide covers the full scope of changes.

What Else Changes in v1beta1

The new schema is not just a variable rename — it is a structural cleanup informed by years of community feedback:

• Component imports simplified — component publishing for imports is cleaner and more composable
• Package templating — standard Go templates replace custom ###ZARF_*### syntax across the board
• documentation renamed to attachments
• Deprecated Kubernetes API migration scaffolding removed (clean up your manifests before upgrading)

Existing 0.x packages work via the migration tooling, but new packages should target v1beta1 from day one. The default init package is now v1beta1.

Keyless Signing Is Now the Default

The 1.0 init packages ship signed with Sigstore keyless signing — no private key required. In GitHub Actions, Zarf detects the OIDC environment automatically and signs using Fulcio. The Sigstore TrustedRoot is embedded directly in the Zarf binary, so verification has no external network dependency even on the air-gapped side. Package bundles include Rekor inclusion proofs for auditability.

Key-based signing is still supported for environments without OIDC. This is not a forced change, but if you are building new packages, keyless is the preferred path.

Why 1.0 Is Actually Significant

The version number matters more here than it typically does in open source. Prior to 1.0, the package format was not stable — an upgrade could silently change how packages were structured. Teams building internal tooling on top of Zarf were accepting that risk. The 1.0 release is an explicit commitment: the format is stable, the API is stable, and breaking changes will follow a proper deprecation process. Under OpenSSF stewardship, that commitment is backed by community governance rather than a single vendor’s roadmap priorities.

The practical implication: if your team deferred adopting Zarf because of format instability, that objection is gone.

The AI Angle Worth Watching

Defense Unicorns’ LeapfrogAI — an air-gapped LLM deployment platform — uses Zarf under the hood to ship models into disconnected environments. As AI agents get deployed in regulated industries (healthcare, finance, defense), delivering model weights, vector databases, and inference servers into air-gapped infrastructure becomes a real engineering problem. Zarf 1.0’s stability makes it a credible foundation for that use case in a way the 0.x releases could not quite claim.

What to Do Now

If your team is on Zarf 0.x, the path forward is:

1. Read the official 1.0 announcement and the linked migration guide
2. Run the included migration tooling on your existing packages
3. Audit any CI scripts for --set-variables calls and replace with --set-values
4. Update any ###ZARF_VAR_*### templates to standard Go templates in your zarf.yaml files
5. Test deploys against the v1beta1 init package before promoting to production

The GitHub repository has the 1.0 release and full migration docs. The Cloud Native Now writeup from KubeCon has additional context on the release timing and community reception.