From Cloud Codebase to Sealed Box: Porting Software Onto a Chassis Build

An ISV that decides to pursue a sealed appliance for one buyer usually starts with a reasonable but wrong mental model: that the process looks like packaging the existing SaaS product into a container and shipping the container on a server. Docker made that assumption plausible for a lot of ordinary enterprise software, and for stateless, network-reachable services it is often close enough to true. It is not true for a product whose cloud architecture assumes an internet connection is always available, because that assumption is load-bearing in more places than most engineering teams initially realize, and finding all of them is most of the actual work in a Chassis engagement.

The assumption that has to be found and removed

Cloud software leans on connectivity constantly, in ways that are easy to overlook because they never fail during normal operation. License checks call home. Feature flags resolve against a hosted service. Telemetry and crash reporting stream out continuously. Model or data updates pull from an object store the vendor controls. Authentication often defers to an identity provider that lives outside the product entirely. None of these are exotic decisions. They are the default shape of software built for a world where the network is assumed reachable, but every one of them becomes a hard failure the moment the product is expected to run inside a facility with no outbound path at all.

The first phase of a porting effort is an audit, not a build: walking the codebase and its infrastructure dependencies systematically to find every place connectivity is assumed rather than requested. That audit is done jointly, because the ISV's engineers know where the logic lives and Element 31's engineers know what a genuinely air-gapped environment will and will not tolerate. The output is not a rewrite plan for the whole product. It's a specific list: this license check needs a local equivalent, this telemetry stream needs to become local logging, this update mechanism needs to become a controlled offline import path, this external identity provider needs a local directory service the appliance can host itself.

What actually gets rebuilt, and what doesn't

Scope matters here, because the instinct to assume "everything changes" is both wrong and unhelpful. The application logic an ISV has spent years refining, the actual product behavior its buyers pay for, is usually the part that changes least. Business logic doesn't care whether it's reading from a database on the other side of the internet or a database three feet away in the same rack; the query still runs, the result still comes back.

What changes is the seam between that application and everything outside it. Authentication moves from a hosted identity provider to a local one running on the appliance itself. Licensing and entitlement checks move from a network call to a mechanism that can validate against cryptographic material sealed into the hardware. Update delivery moves from a continuous pull against a cloud registry to a discrete, verifiable import process: a package brought in on approved media, checked against a signature, applied under an operator's authority, rather than a service quietly pulling whatever a remote server decides to serve it. Observability moves from a hosted dashboard to logs and metrics that stay inside the appliance's own boundary, because a monitoring pipeline that phones out is itself a connectivity assumption the environment won't tolerate.

This is real engineering effort, not a config flag, but it is bounded effort. It touches the product's infrastructure edges, not its core. An ISV that goes into a Chassis engagement expecting a rewrite is usually surprised at how much of the codebase survives untouched once the connectivity seam is properly isolated and replaced.

Where Substrate picks up the load

This is the point where Substrate matters concretely rather than abstractly. The same platform that underlies Forge and Czar handles the category of problems every ISV would otherwise have to solve for itself, one bespoke integration at a time: encrypted storage and key management, integrity verification of what's running, a local identity and access layer, and governed connectivity primitives for the narrow cases where an appliance does need a tightly scoped, audited path to something outside its own boundary rather than either full internet access or total isolation.

An ISV's engineers do not need to become experts in tamper-evident hardware or offline cryptographic attestation to get their product onto a Chassis build. They need to understand where their product currently assumes a network and replace those assumptions with calls into interfaces Substrate already provides. That division of labor is what keeps a Chassis engagement from turning into a from-scratch security engineering project for every ISV that walks through the door. The hard, generalizable parts of "how do you make software trustworthy without a network" are solved once, underneath the lineup, and each engagement spends its effort on the parts that are actually specific to that one product.

Data migration and the offline update problem

Two problems tend to surprise ISVs that haven't done this before, and both are worth naming directly.

The first is initial data. A cloud product usually launches empty and fills up over time as the customer uses it. An appliance headed to a secure facility often needs to arrive with a meaningful starting state: reference data, prior customer data being migrated off the ISV's cloud, model weights, whatever the product needs to be useful on day one, because there may be no practical way to stream that data in afterward. Getting that initial payload onto the appliance, verified and in a state the running product can actually use, is provisioning work that has to be designed deliberately rather than left as an assumption that "the customer will just upload it later" through a network path that won't exist.

The second is what happens after deployment. Cloud software updates continuously and invisibly; a sealed appliance cannot, by the buyer's own requirement. That doesn't mean the appliance never changes. It means updates become a discrete, deliberate, auditable event instead of a background process. What that update mechanism looks like, how frequently it runs, and who has authority to apply it are questions answered per deal, based on the buyer's own policies about how change is allowed to enter their environment at all. Some environments want updates rarely and with heavy review; others want a tighter cadence. Neither is a default. It's a decision made with the buyer's constraints in front of the engineering team, not a knob the ISV sets once and forgets.

A subtler problem sits underneath both: an ISV's existing test suite almost certainly assumes the cloud environment it was written against, mocked or real calls to the services the product depends on in production. Once those dependencies are replaced with local equivalents, a meaningful part of that test suite needs to be re-pointed to exercise the appliance's actual runtime environment instead. Skipping this is how a build that passes every existing test still fails the first time it boots disconnected, because the tests were never checking the thing that changed. A Chassis engagement typically includes staged validation before the unit ships — running the ported product disconnected, the way the real site will be disconnected, so failures surface in a lab rather than on a loading dock.

What the ISV owns versus what Element 31 owns

The cleanest way to describe the division of responsibility is this: the ISV owns correctness of its own product — the business logic, the behavior their buyer is actually paying for, and the decisions about what that product should do once it's running disconnected. Element 31 owns the hardware, the sealed runtime environment, the physical and cryptographic integrity of the box, and the Substrate interfaces the ported product integrates against. The porting work itself happens at the boundary between those two areas of ownership, which is exactly why it has to be a collaborative engineering effort between both teams rather than something either side can complete alone by throwing a finished artifact over a wall.

Framed that way, the goal of the process described here isn't to turn an ISV's cloud product into something unrecognizable. It's to relocate the small number of places where that product currently depends on a network it won't have, replace each of them with an equivalent that works inside a sealed boundary, and verify the result actually behaves the same way the buyer expects — so that what ships is still, recognizably and functionally, the ISV's own product, running somewhere its cloud version never could.