The offline update bundle: everything it has to carry across the fence

An offline update bundle is 1 artefact, signed and self-describing, that takes a disconnected system from a known version to another known version without touching a network. The test that implies is the only one that matters: after the bundle reaches the plant, the installer may read nothing it did not bring. Not a package index, not a container registry, not a font, not a revocation list, not a licence server — including after the reboot at the end.

Most failed air-gapped installs are not sophisticated. They are a dependency that resolved silently on the build machine and does not exist on the floor, found at 02:00 in a 3-hour shutdown window by an engineer with no way to fetch it. The bundle exists to move that discovery into the build pipeline, which is why it sits at the centre of on-premise, edge and plant data control rather than at the end.

What is inside, field by field

The model row is what separates industrial bundles from ordinary software ones. Weights, runtime and class list must move together, because a mismatch does not crash — it relabels, silently, for as long as it takes somebody to notice. A plant self-hosting models inside the fence owns that update path in full, part of the cost weighed in when plant text has to stay on site.

If the installer needs the internet, the bundle is not an update. It is a download script with a filename.

What the receiving site checks before anything is applied

Verification happens on the box, by the box, before a single file moves into place. The signing key must already be resident, delivered out of band at commissioning: a public key travelling inside the bundle it authenticates verifies nothing.

1. Verify the detached signature over the manifest with the key already on the machine. On failure, delete the bundle rather than investigating it in place.
2. Recompute the SHA-256 digest of every listed file and compare. Partial transfers across removable media are common enough that this step earns its keep alone.
3. Compare the installed version against the manifest's minimum current version, and refuse a site too far behind with the intermediate bundle named in the error.
4. Dry-run the environment checks: free disk against payload plus retained version, GPU driver and runtime versions, and confirm the rollback target is present.
5. Stage into a new directory or image reference without switching over. The upgrade is now fully prepared and nothing is live.
6. Switch in the window, run a health check that exercises a real detection rather than a status endpoint, and keep the previous version until a named person signs it off.

Pinning, and the rollback that must already be on the box

Pinning on a disconnected site is stricter than anywhere else, because nothing can be resolved later. Every component is pinned by content digest rather than by tag or version range, so 1 bundle installed on 12 sites over 4 months produces 12 identical systems. A floating tag here is a guarantee that 2 plants running the same version are not.

Rollback follows the same logic: the previous version must be resident before the upgrade begins, with its own backward migration. A plan that starts by retrieving an old image is not a plan on a site with no internet — it is a site visit. Budget disk for 2 complete versions at commissioning and the requirement stops being an argument.

4 things that look like a bundle and are not

• An installer that runs a package manager. It works in the build environment and on the vendor's laptop and nowhere on the plant network, and where the server sits makes that certain rather than likely — see which network layer an AI server belongs on.
• An archive with no manifest. Without a declared target version and a file list with digests, the site cannot verify what it has, cannot tell whether the transfer completed, and cannot say afterwards what it applied.
• A payload with no rollback. Half an update is a state nobody designed, and on a disconnected site it is the state you stay in until somebody drives out.
• A bundle that covers the server and forgets the cameras. Analytics pushed into the camera makes camera firmware part of the release surface, and it has to travel in the same artefact — 1 of the ongoing costs weighed in analytics in the camera or analytics on a server.

This is release engineering rather than deployment scripting, and it is worth doing before the 1st site rather than after the 3rd. A pipeline that emits a signed, verifiable, self-contained artefact on every build is normal product and platform work, and it makes a manufacturing and industrial vision system supportable across sites that will never all be online at once.

• air-gapped
• release engineering
• plant IT
• on-premise