Notes from an air-gapped deployment

We get asked some version of "does air-gapped really work?" on most discovery calls. The honest answer is yes, but the more useful answer is to describe what an air-gapped install actually looks like, because the experience differs from cloud installs in ways IT teams care about.

This post is a sanitized walkthrough of a recent fully-disconnected install. Customer details omitted.

What "air-gapped" means here

The lab network had no outbound internet access. No traffic could leave the perimeter, including to package mirrors, license servers, or telemetry endpoints. The install needed to complete from a single offline bundle, and the running system needed to operate without any outbound traffic.

We've shipped DataTorch installs across a range of these constraints. This one was on the strict end.

What we shipped

A single offline bundle (datatorch-v0.4.x.tar.gz) containing the application, dependency images, a Postgres bundle, a Redis bundle, and a small CLI to drive the install. Total size around 1.2 GB. The bundle was transferred onto the customer's network via their normal procedure (in this case a vetted USB drop from a clean staging machine), not over the network.

The install itself

The customer's infrastructure team ran the install on their Kubernetes cluster (RHEL 8 nodes, Kubernetes 1.27). The CLI took a few minutes to:

1. Validate the environment (versions, resource quotas, namespace permissions)
2. Load images from the offline bundle into the cluster's internal registry
3. Start the services in dependency order
4. Run health checks
5. Print the local URL the SMEs would use

We verified one more thing before signing off: no outbound traffic. We watched the network monitor with the customer's security engineer. Nothing left the perimeter: no telemetry, no license phone-home, no support-channel callout. That was the point.

What's harder air-gapped

A few things we tell customers upfront.

Updates ship as bundles, not as apt-get upgrade. When we release a new version, we ship you an updated offline bundle, and you run the same install flow. Cadence is yours, not ours.

Support is via the channel you control. We can't tail logs on your cluster. If something needs investigating, we work from logs and screen-shares your team initiates. Slower than SSH-in, by design.

Some integrations are out. If you wanted a Slack notification on pipeline completion, that's an outbound call. We won't make it. We'll send a webhook your internal notification system can route.

When air-gapped is the right choice

The customers who choose this configuration are doing it for one of two reasons: a regulatory requirement that data and inference paths stay local, or an IP-driven decision (proprietary models or proprietary assays they don't want a vendor anywhere near). Sometimes both.

If your lab is in that bucket, the install pattern above is what we'd run with you. If you have constraints that make even this approach too open, we'd want to talk through them before recommending anything.

Book a call to walk through your environment.