Updating an air-gapped appliance

The standard objection to air-gapped deployment arrives in the first meeting: if it cannot reach the internet, how does it stay current? It is a fair question with a common bad answer: connect it, briefly, now and then. This note describes the alternative Element 31 builds around: the release bundle, a complete, versioned, signed unit of change that crosses the gap on physical media and is verified before a single byte of it is applied.

Why "temporarily connect it" is not a maintenance strategy

An air gap is not a network setting; it is a claim your security posture makes to an accreditor. The claim is categorical — this system has no path to the outside — and categorical claims do not survive exceptions. A quarterly maintenance window in which the appliance briefly joins a network converts the claim from "no path exists" to "a path exists and we try to be careful with it," which is a different and much weaker thing to defend. It also concentrates risk at exactly the wrong moment: the system is most exposed during the one operation, updating, that most needs to be trustworthy.

If the gap is going to mean anything, updates have to work with it rather than around it. That means the unit of maintenance must be something a person can carry.

What a release bundle contains

A bundle is the whole change, not a pointer to one. It packages the platform software image, the model artifacts for the deployment's pinned model set, security patches, and the manifest that describes every item: versions, hashes, and the exact set of appliance configurations it applies to. Bundles are complete rather than incremental in the sense that matters: applying one never requires fetching anything, from anywhere, ever.

Each bundle is assembled and signed by Element 31 as a single unit. The signature covers the manifest, and the manifest's hashes cover every artifact, so there is one chain of custody from our build infrastructure to your loading dock. The bundle travels like any other controlled item, on physical media, under your handling procedures, because for disconnected sites, the courier is the network, and couriers can follow rules that packets cannot.

Verification at the appliance

At the appliance, trust is established before anything is installed, in a fixed order. The signature is checked against keys already resident in the unit. The manifest is parsed and every artifact hash is recomputed and compared. The bundle's declared compatibility (hardware tier, current installed version) is checked against the machine it is actually sitting in.

Any failure, at any step, stops the process outright. There is no partial-apply, no "install what passed," and no operator override that skips the signature. A failed verification leaves the appliance exactly as it was, running the software it was already accredited to run, with the failure itself written to the log. The design assumption is unglamorous but load-bearing: media gets damaged, the wrong disk gets carried to the wrong site, and the verification step is where those ordinary mistakes are caught.

The record, and why it matters later

Every applied update becomes a permanent entry in the appliance's local audit record: what bundle, what versions, when, verified how. This is the part that looks like bookkeeping and turns out to be strategy. Months later, when a review board asks why the system's behavior changed in March, the answer is a specific signed bundle with a specific manifest — not a reconstruction from emails. The same record is what makes the appliance's core promise auditable over its whole life: at any moment, the software running is a known version that arrived through a signature check, and the entire history of how it got there is queryable on the machine itself.

The gap, in this design, never closes. The system stays current anyway. Those two sentences are only in tension if updating requires a connection, and that requirement was always a design choice, not a law of nature.