Moving or incomplete artifacts
Tag-only mirroring can change identity or omit charts, tools, metadata and transitive dependencies.
Restricted and disconnected environments
Make Kubernetes operations verifiable without depending on public egress.
ClusterPilot’s release and registry contracts are designed to preserve exact subjects, digests, metadata and evidence while artifacts move through a customer-controlled promotion path.
Operational challenge
Disconnected operation fails when the artifact set is incomplete.
A mirrored container image alone is not enough. Operators need compatible tools, Kubernetes and add-on artifacts, trust material, signed metadata and a repeatable way to prove the promoted set.
Trust mismatch
Private CAs, registry endpoints and host trust stores can diverge between control plane, agents and targets.
Unprovable promotion
Teams may know that files were copied without retaining a digest- and approval-bound release record.
Enterprise value
Treat distribution as part of the operating contract.
The value comes from shared state, explicit ownership and reviewable execution.
Immutable inventory
API, agent, tool, Kubernetes and add-on subjects are selected by exact digest and compatibility metadata.
Controlled promotion
Harbor or another approved registry becomes the customer policy and promotion boundary.
Retained verification
Checksums, signatures, SBOM, vulnerability evidence and provenance remain associated with the promoted release.
Controlled workflow
A verifiable air-gap path
The same artifact identity is preserved from connected staging through the restricted runtime.
Resolve the release set
Select the exact release, compatibility line, provider tools, Kubernetes artifacts and approved add-ons.
Verify before transfer
Validate checksums, signatures, digests, SBOM and provenance in the connected zone.
Mirror and promote
Transfer the complete inventory, preserve digests, apply customer policy and record promotion approval.
Attest the runtime
Confirm registry trust, agent compatibility, runtime digests and retained evidence before lifecycle work.
Evidence
Prove what crossed the boundary.
Operators can connect the approved inventory to the runtime subjects and the operation that consumed them.
Release identity
Version, commit, immutable subjects, exact digests and signed compatibility metadata.
Promotion record
Source and destination registry, policy result, actor, timestamp, checksums and approval.
Runtime confirmation
Agent/tool identity, pulled digest, trust posture, operation result and retained artifact evidence.
Honest product boundary
Deployment-specific validation remains required
- Air-gap readiness depends on the complete customer network, registry, DNS, time and private-CA design.
- A restricted environment must be tested with the exact release and artifact inventory; documentation alone is not acceptance.
- ClusterPilot does not claim that every third-party add-on is offline-ready without its own dependency review.
Frequently asked questions
Questions about Air-Gapped Kubernetes Operations
Clear answers about fit, boundaries and the evaluation path.
Does ClusterPilot require internet access at runtime?+
The documented registry and air-gap model supports customer-controlled distribution. The exact dependency inventory and network design must be validated for the selected capabilities.
Can images be mirrored by tag?+
The supported release posture is digest-pinned. A moving tag alone does not preserve artifact identity or provide sufficient verification evidence.
Is a private CA supported?+
Private trust is part of the documented deployment boundary. The CA must be installed and validated consistently across the control plane, agents, registries and target hosts.
Capability scope: v0.0.1 release candidate. Review the current release boundary →
Start with a measurable workflow
Translate the requirements into a bounded technical evaluation.
We will review the environment, operational bottleneck, control boundaries and evidence needed for a decision.
hello@clusterpilot.de