Field guide
Offline Patching for Air-Gapped Fly-Away Kits, With Rollback
To patch an air-gapped fly-away kit, bring updates in as a signed bundle on removable media, verify the signature on the kit before anything is unpacked, check that the bundle is meant for that kit, then apply it with the previous version kept as a rollback point. A checksum alone proves the copy is intact, not who built it.
Why patching stalls on a disconnected kit
A deployable kit that never touches the internet cannot pull patches from a vendor mirror. Updates have to be carried in by hand, which raises three questions every program eventually faces: how do you know the media came from your supplier, how do you know it applies cleanly to this kit, and what happens if it fails halfway through at a forward site with no engineer on hand.
Without good answers, kits fall behind. Teams delay updates because a failed patch in the field can take the kit out of the mission, and a kit that is months behind is a finding waiting to happen.
What a defensible offline patch process looks like
Authenticate before you unpack. The bundle should carry a detached signature that the kit checks against keys it already holds, with no network call, certificate authority or license server in the path. A checksum is useful for catching a bad copy, but it does not prove who produced the bundle.
Check fit before you change anything. The bundle should describe itself: what it contains, which kits it is for, how much disk it needs and any prerequisites. Those checks should run, and be able to refuse, before a single live file moves.
Keep a way back. Each apply should preserve the previous version so a failed step can be reversed, and every failure should leave a record an engineer can read remotely.
How Rhombus patches a kit offline
Rhombus updates arrive as signed sustainment bundles that carry package repositories, container images, update steps and release notes. Operators upload a bundle through the console or load it onto the kit from USB. The kit refuses to unpack a bundle without its signature, verifies it entirely offline against signing keys installed on the kit, and checks every component against the signed manifest. A kit also refuses a bundle that is not meant for it.
Preflight checks run before anything changes, so a refusal leaves the kit exactly as it was. The console shows the bundle's title, type and summary, and records the files each repository component added, updated or removed. The previous repository generation is kept on the kit, and if a required update step fails, the repository changes from that bundle are rolled back. Every failure produces a diagnostic package for remote triage.
Applying is always operator-driven. Each night the kit scans its virtual machines for pending updates against its own local mirror, so the console shows what is outstanding. Scheduled repository sync from the internet ships turned off, and stays off unless the kit is set up to allow it.
Rollback, stated precisely
Rollback on Rhombus restores the kit's previous repository generation. It is the safety net for the bundle itself. Plan patch windows the way you would on any production system: apply the bundle, patch the machines from the refreshed mirror, then run validation to confirm the kit is healthy.