How signed updates reach the appliance
Updates to Substrate are signed bundles. The customer downloads them from the portal or carries them in on media; the appliance verifies the signature, loads the release, and keeps the previous one.
· 4 min read
IN SHORT
Substrate updates arrive as signed bundles that the customer brings to the appliance, never as something the appliance fetches. On a connected site the customer downloads the bundle from the portal; on an air-gapped site it is carried in on media. The appliance verifies the signature before loading, records the software load in the node's provenance record, and keeps the previous signed release available for rollback.
An update is a moment of trust. Something new is about to run on a machine that serves the floor, and the site needs to know exactly what it is, where it came from, and how to undo it. Substrate handles that moment with one artifact and one rule: the update is a signed bundle, and the appliance never goes looking for it.
The customer brings the bundle to the appliance. The appliance checks the signature, loads the release, writes down that it did, and keeps the old release within reach. Everything else about the process follows from those steps.
The bundle
A Substrate release is packaged as a single signed bundle. The signature covers the whole bundle, so there is no partial update and no mix of old and new pieces. The bundle is the same artifact regardless of how it reaches a site; a connected distribution center and an isolated plant apply the identical file.
Bundles are published to the customer portal. The portal is also where support, billing, and remote-session requests live, and it is the one place a customer interacts with Element 31 about a running appliance. The appliance itself has no account on the portal and no path to it.
Two ways in, one verification
On a connected site, someone on the customer's team downloads the bundle from the portal to a workstation and moves it onto the facility network. The appliance has no outbound route that would let it fetch the bundle itself, and it does not need one. The download is the customer's act on the customer's machine.
On an air-gapped site, the bundle is carried in on media. The customer downloads it elsewhere, writes it to removable storage, and brings it through the door the same way every other artifact enters the plant. Nothing about the bundle is different, and nothing about the appliance's behavior is different either.
In both cases the appliance verifies the signature before anything is loaded. A bundle that does not verify is refused, and the refusal is recorded. The running release is not touched. The site gets a fresh copy of the bundle and tries again, and the only cost of the failed attempt is a line in the record saying it happened.
Loading and recording
Once verified, the release is loaded. Because the software image is sealed and read-only, loading a release replaces the image rather than patching it in place. The node now runs exactly the signed release and nothing else.
The load is written to the node's provenance record, alongside the record of its integration and sealing. For any Czar in a Grid, the site can read back which release it is running, when that release was loaded, and which release it ran before. On a Grid, nodes can be updated in sequence so the pool keeps serving while each one reloads. A node that has just loaded a release attests what it is running before it rejoins the Grid and accepts work again, so a mismatched node cannot slip back into the pool.
Watchman picks up from there. Its continuous verification is now against the new signed image, and any deviation from it lands in the append-only record as before.
Keeping the way back
The previous signed release stays available. If a new release misbehaves on the floor, the site rolls back to the one it was running before. The rollback is a local operation; it needs no connection and no outside party. The provenance record notes the rollback the same way it noted the load, so the node's history reads as a sequence of signed states with no gaps.
This is the part that lets a site update with some confidence. The question before applying a release is not whether it is perfect but whether it can be undone. On Substrate it can, cleanly, from inside the building.
What the site controls
The site decides when a release is applied, in what order across a Grid, and whether to keep it. Element 31 publishes bundles and signs them; the customer carries them in and applies them. Nothing is pushed, nothing is fetched, and nothing happens on a schedule the site did not set. The security overview at /security describes how signing and attestation fit together to make that true.
Questions this raises
- Does the portal connect to the appliance to push an update?
- No. Appliances never connect to the portal, and the portal never connects to an appliance. The portal is where a customer downloads a bundle; getting it onto the facility network and applying it is the customer's act.
- What happens if a bundle has been altered in transit?
- The signature will not verify and the appliance refuses the bundle before loading any of it. The refusal is recorded. The site obtains a fresh copy and tries again; nothing on the running release was touched.
- How does a Czar Grid update, node by node or all at once?
- The site chooses. Nodes in a Grid can be updated in sequence so the pool keeps serving while each one reloads, and each node attests what it is running before it rejoins the Grid and takes work again.
KEEP READING