Running Substrate air-gapped
An air-gapped site runs every Substrate service with no path out: serving, retrieval, memory, adaptation, evaluation, and integrity checks, all from inside the enclosure.
· 4 min read
IN SHORT
Substrate runs fully air-gapped. All seven services operate inside the appliance with no path out of the building, including model serving, retrieval over local documents, adaptation on site data, and integrity verification. Updates arrive as signed bundles carried in on media, monitoring is done from inside the site, and support sessions happen only when the customer opens an attested, time-limited window.
Some buildings have no path out and are not going to get one. The plant segment is isolated by design, the security team has spent years keeping it that way, and no inference platform is going to be the reason that changes. Substrate was built with those buildings in mind. It runs air-gapped as a first-class posture, not as a degraded mode.
The short description is that every one of the seven services works with no external dependency, and the operational tasks that usually need a connection, updating and support, are handled by moving signed artifacts and by customer-initiated sessions instead.
What runs inside the enclosure
Inference serves open-weight models from the appliance. Language, vision, speech, embedding, and vision-language-action models are loaded onto the Czar and answer calls over the facility network. Nothing about a request leaves the rack.
Retrieval indexes the site's documents and answers over them with citations. On an air-gapped site the documents are brought to the appliance or read from an isolated store on the same segment. The index lives on the appliance.
Memory keeps agents coherent across sessions, and it lives on the appliance too. Adaptation fine-tunes open models on the site's own data, which is often the strongest reason an isolated site wants a serving pool in the first place: the captures from its own floor are exactly the data it would never send anywhere. Evaluation records every operation locally. Watchman verifies the signed image and the enclosure continuously and writes deviations to an append-only record. Local Bridge sits idle with no routes declared, which is the air-gapped posture expressed in configuration.
How updates arrive
Signed updates are bundles. On a connected site the customer downloads a bundle from the portal; on an air-gapped site someone carries it in on media. The appliance verifies the signature before anything is loaded and refuses a bundle that does not verify. There is no moment where the appliance reaches out to fetch anything, because it has no path on which to do so.
If a release misbehaves, the site rolls back to the previous signed release. The rollback is a local operation and does not need a connection either. The provenance record for each node notes the software load, so the site can show which release each Czar in a Grid is running and when it changed.
How the site watches the platform
Monitoring is from inside. The platform exposes its health, its traces, and its integrity record on the facility network, and the site's own tooling reads them there. There is no external dashboard to log into and no telemetry stream leaving the building. This is true on every posture, not only air-gapped sites, but on an air-gapped site it is also the only way it could work.
Watchman's record is part of what the site watches. Because it is append-only and written locally, an operator can review the full integrity history of a node without any external service. A deviation in the signed image or a tamper indicator on the enclosure appears in the same place the site already looks.
How support happens
Support, billing, and update downloads live on the customer portal. Appliances never connect to the portal, on any posture. When a site needs a remote session, the customer initiates it. On a sovereign site that means opening an uplink window, and the window requires the customer's attestation first: that data disks are detached, the network is isolated, the console is supervised, and the person opening the window has the authority to do so. The window carries a hard expiry. When it closes, the site is isolated again, and the record shows that it happened.
Most support on an air-gapped site never needs a window at all. The site's own team, often with help from an integrator, handles day-two operation using the records and tooling on the facility network. The window exists for the cases that need outside eyes, and it is built so the site stays in control of when those eyes are present.
What the site gives up
Nothing in the platform. The same seven services, the same API, the same models. What an air-gapped site declines is a set of conveniences that Substrate was never designed to rely on: automatic fetching, external dashboards, and vendor-side telemetry. Since the platform does not use those on connected sites either, the air-gapped site is not running a reduced product. It is running the product as it was meant to be run, with no routes declared. The security overview at /security describes the integrity model this posture rests on.
Questions this raises
- Do the models work without a connection?
- Yes. The open-weight models Substrate serves are loaded onto the appliance and run there. Inference, embedding, speech, vision, and VLA models need no external service at request time, and adapters trained on site are stored on site.
- How does an air-gapped site get a new model?
- The same way it gets any software: as a signed bundle carried in on media and verified by the appliance before it is loaded. The site can also adapt models it already has using Adaptation, entirely on the appliance.
- Can an air-gapped site later become connected?
- Yes. Posture is a per-site configuration, not a product line. A site that declares a Local Bridge route to an on-premise system becomes connected to that system and nothing else, and it can withdraw the route later.
KEEP READING