Air-gapped by design: shipping Kimo on-premise

Most “on-prem” SaaS is the cloud product with the telemetry turned off and half the features missing. We decided early that Kimo Defense Intelligence would treat air-gapped as the primary deployment target, and that the cloud would be the special case. That decision shaped the build system, the update channel, and even the AI features.

§01Start from the threat model

Customers running air-gapped enclaves worry about three things, in this order:

1. 1Exfiltration — no byte of data, metadata or usage should leave the enclave, ever.
2. 2Supply-chain integrity — what they install is exactly what we built, and they can prove it.
3. 3Operability — their team can install, upgrade and troubleshoot without us in the room.

Everything below maps to one of those three.

§02Zero phone-home, enforced

Removing telemetry calls is easy. Proving they are gone is harder. Our on-prem build compiles with a sovereign flag that strips every outbound client at build time — analytics, crash reporting, update checks, font CDNs, map tiles. CI then boots the bundle in a network namespace with no route and fails the build if any process attempts a DNS lookup.

123456789# Boot the full stack with no network route and record any egress attempt
unshare --net --map-root-user ./kimo-stack up --profile sovereign &
sleep 60
./kimo-stack smoke-test --all-features

# Fail if anything tried to resolve a hostname
if grep -q "resolve" /var/log/kimo/egress-audit.log; then
  echo "egress attempt detected" && exit 1
fi

Map tiles, fonts, icons and the language model weights all ship inside the bundle. The basemap uses vector tiles generated from OpenStreetMap extracts for the customer’s area of operation.

§03Signed bundles and reproducible builds

Each release is a single archive containing container images, migrations, model weights and a software bill of materials (SBOM). The archive and every image inside it are signed. Customers verify on a transfer station before media crosses into the enclave:

1234567891011# 1. Check the bundle signature against our published key
cosign verify-blob \
  --key kimo-release.pub \
  --signature kimo-4.8.2.tar.sig \
  kimo-4.8.2.tar

# 2. Check every image digest listed in the SBOM
kimo-verify sbom kimo-4.8.2.spdx.json --images ./images/

# 3. Optional: rebuild from source and compare digests
make reproducible VERSION=4.8.2 && sha256sum -c digests.txt

§04Offline updates without drama

Upgrades are the moment on-prem deployments go wrong. We made them boring with three rules: migrations are always forward-compatible for one version, every upgrade runs a pre-flight check that reports what will change before touching anything, and rollback is a single command that restores both images and schema.

§05No second-class features

The hardest part was Ask Kimo. In the cloud it calls a hosted language model. On-premise, it runs a quantised open-weights model on the customer’s own GPUs — or CPU-only for small deployments, with longer response times. Because Ask Kimo grounds every answer in the semantic layer rather than free generation, a smaller model loses surprisingly little accuracy.

§06Supporting what we cannot see

With no remote access, support relies on a diagnostic export: a redacted archive of logs, health checks and configuration that the customer reviews before carrying it out. It contains no data rows and no query text by default. Our support engineers can replay most issues from it on a mirrored lab environment.

If you are evaluating an air-gapped deployment, the on-premise install guide covers hardware sizing and the transfer workflow, and the security page lists certifications and our disclosure policy.