Updating an air-gapped Grid

An air-gapped site has made a clear decision: the Grid has no path out, and no path in except the robots it serves. That decision does not freeze the software. Updates still arrive. They arrive the old way, carried through the door on media by a person with the authority to do it, and the Grid treats that media with the same suspicion it would treat a network.

This is the procedure as it runs on a sovereign floor. It is deliberately dull, and the dullness is what makes it repeatable.

Where the bundle comes from

Element 31 publishes updates as signed bundles. A site team member retrieves the bundle through the customer portal. That retrieval happens on a connected machine that is not the appliance and does not sit on the isolated segment: an office workstation, a laptop in the IT room, whatever the site already uses for ordinary business.

The appliance never does this itself. Under any posture, air-gapped or connected, customer appliances do not connect to the portal. The portal is a place where people go to get things; it is not a place that reaches into the building. That distinction holds on every site, and on an air-gapped site it is simply reinforced by the physical absence of a route.

Crossing the gap

The bundle moves from the connected machine to media, and the media moves across the floor to the rack. Who may carry it, which media is permitted, and how it is logged are matters of the site's own policy. Element 31 does not dictate that policy; it only requires that what arrives at the node is the signed bundle, unmodified.

Good sites treat this walk as a controlled handoff rather than an errand. The person carrying the media is named. The time is noted. The media is checked in, used, and checked out. None of this is required by the appliance, but all of it makes the site's own record stronger when someone later asks how a particular image came to be running.

What the node does with it

When the bundle is presented, the node verifies its signature before touching anything. A bundle that fails verification is refused outright; there is no partial application and no prompt asking an operator to override. If the signature verifies, the node applies the new sealed, read-only image.

Then it attests again. A node does not resume serving robots or accepting tasks until it has attested what it is now running. The result goes into the record beside the earlier attestation, so the site can read, for each node, the image it ran before, the image it runs now, and the moment the change occurred. That record is local and belongs to the operator.

Updating without stopping the floor

The site chooses the order and the pace. On a Grid of several nodes, the usual practice is one node at a time: take a node out of service, update it, let it attest, return it, and move to the next. The rest of the pool keeps serving throughout.

Robots are built for this. Each one keeps its own on-board model and falls back to it whenever the pool cannot answer within its budget. During a staged update, a robot that would have been served by the node under maintenance either gets its answer from another node or falls back. Either way it behaves as its vendor built it to, and safety never depended on the pool in the first place. A site that wants zero overlap can also schedule the update for a shift when the floor is quiet, but the design does not require it.

The practical rule most sites adopt is to keep the previous signed bundle on controlled media alongside the new one. If the new release behaves in a way the site does not want, the path back is the same procedure in reverse, and the node verifies the older signature exactly as it verified the newer one. Rolling back a release on the pool walks through that case.

What this means for the site

An air-gapped Grid stays current without ever being reachable. The site decides when to update, carries the update in by hand, and gets a record of the change written by the node itself. Nothing about the procedure asks the site to trust a network it chose not to have. When the site also needs a remote session rather than a file, the sovereign path is an uplink window with the customer's attestation and a hard expiry, which is a different procedure for a different purpose.