Skip to main content

Platform

Deployment topologies

We deploy into five principal topologies, compared below across data residency, egress, identity, update path, latency and operational burden. The final column deserves particular attention, as operational burden is generally the strongest predictor of whether a system remains well maintained a year after go-live.

TopologyData residencyEgressIdentityUpdate pathLatencyOperational burden
On-premisesYour datacentreNone requiredYour AD / LDAPChange windowLowest, no network hopHighest. You own the hardware
Private cloud (VPC)Your tenancyControlled, auditableYour IdPStandard pipelineLowModerate
Sovereign cloudNamed jurisdictionRegion-boundYour IdPStandard pipelineLow to moderateModerate
Air-gapped enclaveIsolated enclaveNone, physicallyEnclave-localSigned media, change boardLowestHighest, supply line is a project
Edge / disconnectedAt the siteIntermittentCached credentialsSync on contactLowest locallyHigh, fleet management

Choosing between them

In most engagements the choice is resolved by four questions. They are asked in this order because each one narrows the available options rather than widening them.

  1. 01Can the data leave your estate at all?

    No → On-premises or air-gapped.·Yes → Continue.

  2. 02Must it stay within a named jurisdiction?

    No → Private cloud (VPC).·Yes → Sovereign cloud.

  3. 03Can the model weights be transferred over a network?

    No → Air-gapped, with a signed-media supply line.·Yes → Continue.

  4. 04Does the workload run where connectivity is unreliable?

    No → Choose from the above.·Yes → Edge, with a sync strategy and cached identity.

The air-gapped supply line

The physical transfer is straightforward. The harder requirements are demonstrating, months afterwards, precisely which artefact was running on a given date, and establishing a repeatable process that a security team is prepared to approve on an ongoing basis.

Getting model weights into an air-gapped enclaveOutside the boundary, weights are downloaded, scanned, hashed and signed, then written to removable media along with a manifest. Media crosses a one-way transfer point under change control. Inside the enclave, the manifest signature and hashes are verified, the artefact is admitted to an internal registry, and only then is it deployed to the serving tier. Nothing returns across the boundary except an approval record generated inside.OUTSIDEFetch weightslicence checkScan + hashmalware, SBOMSign manifestdetached signatureremovable mediaAIR GAP, one-way, under change controlVerify signaturefail closedInternal registryadmitted artefacts onlyServing tiervLLM / NIMChange record + approvalgenerated inside, never leavesAudit log + telemetryretained locallyThe hard part is not the transfer. It is proving, months later, exactly which artefact ran on which day.
Figure. Model weights enter under a signed manifest and verification fails closed. No data returns across the boundary.

Start with the constraint.

Most of these projects are shaped by what you cannot do rather than what you want. Data that cannot leave the estate, a model you cannot host with a third party, a decision somebody has to justify to a regulator. Tell us yours and we will say honestly whether we can work inside it.

Talk to an engineer