Zarf: Packaging Kubernetes Workloads for Airgap Deployment

The Airgap Problem Zarf Solves

Delivering software to a Kubernetes cluster that has no internet access is a logistics problem. You need container images, Helm charts, Git repositories, and configuration values, all transported in a way that can be installed without connectivity. Zarf addresses this by packaging those dependencies into a single compressed file that can be carried on a USB drive or shipped as an artifact. The target audience is teams working in edge, embedded systems, secure cloud, data centers, or any environment where the cluster cannot reach the outside world. The README frames it as "Develop Connected, Deploy Disconnected": you build and configure while online, then deploy the resulting package offline.

How Zarf Packages Work

Zarf uses a declarative packaging strategy. A package defines the precise state of an application, including images, Helm charts, and Git repositories, and that state is deployed the same way every time. The package is a compressed file that contains all the parts of the internet your app needs. Under the hood, Zarf includes a built-in Docker registry and a built-in Git server (Gitea). When you deploy a package, Zarf pushes the images and repos into those internal services, so the cluster's workloads pull from local sources. A mutating webhook automatically rewrites pod image paths and pull secrets, and it also updates Flux Git Repository URLs and secret references. This mechanism means you do not have to manually edit manifests to point at the local registry. The design is deliberately vendor-neutral: if you remove Zarf, you can still use the Helm charts it deployed manually.

Getting Zarf Running

Zarf is a statically compiled binary with zero dependencies. You download it, and it runs on any supported OS. The README points to the official getting started guide at docs.zarf.dev/getting-started/ for installation steps. The typical workflow involves three commands: zarf package create, zarf package publish, and zarf package deploy. You can also pull packages from an OCI registry using zarf package pull. To initialize a cluster, you use the zarf init command, which sets up the built-in registry and Git server. For CI, there is a setup-zarf GitHub action that installs any version of Zarf and its init package with zero added dependencies. The configuration is done through a zarf.yaml file, which defines components, variables, and actions, but the README does not show the exact schema, so you will need the docs for that.

Built-in Services: Registry, Git, and Dashboard

A notable feature is that Zarf ships with a Docker registry and a Gitea Git server as part of its init package. This is not just a convenience; it is the core mechanism that makes offline deployment possible. When you deploy a package, Zarf pushes images to the local registry and repos to the local Gitea instance. The mutating webhook then rewrites the Kubernetes pod specs to pull from those local addresses. This design also means you get a K9s dashboard for cluster management and an SBOM viewer for scanning software bills of materials. The SBOM generation is automatic, and the viewer is a web dashboard. If your team already has a registry and Git server, you might see these as redundant, but for a fully disconnected cluster, they are essential.

Limitations and Wrong Use Cases

Zarf is not a general-purpose package manager for online clusters. If your environment has internet access, the extra packaging step adds overhead without benefit. The built-in registry and Git server also consume cluster resources, and you may not want them running if you already have an external registry. The README mentions that a full matrix of supported OSes and architectures is "coming soon," which suggests that cross-platform support is not fully documented. If your workloads rely on dynamic image pulls or external services that cannot be mirrored, Zarf will not help. Also, while Zarf can wrap legacy code, it does not magically make a legacy app airgap-friendly; you still need to ensure all dependencies are captured. The package format is compressed, but there is no indication of size limits, so very large datasets might be impractical.

Alternatives and Their Differences

The most direct alternative is using Helm charts with a manually populated container registry. In that approach, you export images to a tarball, transfer them, and load them into a registry inside the airgapped network. You then run helm install with the chart and point to the local registry. This is a manual process that does not handle Git repos or SBOMs. Another alternative is a GitOps tool like Flux, which can work offline if you have a local Git server, but Flux does not package images or provide a registry. Zarf's difference is that it bundles all these pieces into one declarative package and automates the image path rewriting via a webhook. If you already have a robust offline registry workflow, Zarf may be redundant, but if you want a single tool to handle the whole pipeline, it fills that gap.

Maintenance and Licensing

Zarf is licensed under Apache-2.0, which means you can use, modify, and distribute it freely, including in commercial products. The project is actively maintained, with recent releases v0.84.0 and v0.83.0 in August 2026. The README emphasizes that it is free and open source, and that there is no proprietary lock-in. The maintenance cost for users is tied to the package definitions: you must keep your zarf.yaml files updated as your application changes. The CLI is a single binary, so upgrading Zarf itself is straightforward, but you should re-test packages after each Zarf release. The project also relies on dependencies like Helm, cosign, and go-git, which means you inherit their update cycles. There is no mention of a migration path or upgrade tooling, so plan for manual verification.

Who Should Adopt Zarf

Zarf is a strong fit for teams that regularly deploy to airgapped environments and want to avoid manual image export and manifest editing. It is also useful for DevSecOps pipelines that need SBOM generation and package signing with cosign. If your organization has no existing offline deployment tooling, Zarf provides a cohesive solution out of the box. On the other hand, if you are only occasionally shipping to a disconnected site, the learning curve for package definitions may not be worth it. The README claims zero dependencies and OS agnosticism, but those claims need to be verified against your specific environment. Before committing, check the docs for the exact OS and architecture support matrix, and test a simple package in your own airgapped lab.

Editorial conclusion

Adopt Zarf if your team must ship Kubernetes workloads to airgapped or semi-connected environments and wants a declarative, single-file packaging approach that avoids vendor lock-in. Skip it if your clusters are always online and you already use standard Helm or GitOps workflows, as Zarf adds an extra abstraction layer. Before adopting, verify that your target OS and architecture are supported, test the package signing and SBOM generation in your CI pipeline, and confirm that the built-in Gitea and registry meet your security requirements.

Official sources

1. Official documentation
2. Official README
3. Project repository
4. Release notes