That’s the promise of an air-gapped deployment—and for Kubernetes teams, it’s the difference between theory and production-grade security. But closing the network door is only half the battle. The real work begins when you need to get your Helm chart running inside an environment that will never, by design, reach public registries or fetch dependencies on demand.
What Air-Gapped Deployment Means for Helm Charts
In an air-gapped Kubernetes cluster, every component—images, manifests, configuration files—must be available locally. Helm, by default, will try to pull from chart repositories, fetch dependencies, and reference remote container images. This approach fails immediately without a network path. To succeed, you prepare everything offline before you cross the gap.
Packaging Helm Charts for Air-Gapped Environments
Start with the chart itself. Run helm dependency update in a connected environment to vendor all requirements into the charts directory. Then package the chart with helm package, producing a .tgz file you can move into the secured environment. The chart must be fully self-contained, with no remote references left unresolved.
Handling Container Images
Air-gapped deployment demands that all container images be pulled, saved, and imported into a private registry inside the isolated network. Use docker pull or ctr images pull in a connected staging host, then docker save to produce tar archives. Across the gap, load them with docker load or an equivalent container runtime command, then push to your internal registry. Finally, update your Helm chart’s values.yaml to reference that internal registry for every image URL.