AI that works with the network cable unplugged.
Data.co Control is designed to install, license, update, and operate with no connection to Data.co or the internet. Licenses are signed files, updates arrive on signed media, models are mirrored in, and nothing reports out.
Not a connected product with the internet blocked.
Software built for the cloud often assumes it can reach a license server, a model hub, a telemetry endpoint, or a package registry. Blocking those calls causes failures that surface weeks later. Data.co Control is built so that none of them are needed: every dependency is either inside the release bundle or provided by your mirror.
That means the policy engine, gateways, retrieval, model serving, and audit log operate entirely within the isolated network. app.data.co is never contacted, and no usage data, prompts, or logs leave.
The four things connected software usually phones home for.
Licensing
Signed license files with entitlements and term, verified locally. Renewal is a new file brought across.
Updates
Release bundles with container images, charts, and checksums, signed and verifiable before import.
Models
Weights transferred on approved media, pinned by digest, and registered in the local model registry.
Telemetry
None. Health and usage data stay in local monitoring; support diagnostics are exported only if you choose.
How a release crosses the gap.
Your transfer procedure governs the media. Data.co supplies signed artifacts and verification tooling.
- 1
Download and verify
On the connected side, download the release bundle and verify signatures and checksums.
- 2
Review and transfer
Your security team reviews contents per its procedure and transfers approved media.
- 3
Import
Verify signatures again inside, then import images and models into your local mirror.
- 4
Upgrade
Apply the upgrade in a change window, with the previous release retained for rollback.
What to decide before installation.
- Approved media type and transfer procedure
- Local container registry and artifact storage
- Which models to bring in, and their licenses
- Update cadence your process can sustain
- Local identity provider integration
- Support process without remote access
- Time source for license and log validity
- Hardware spares on site
What an offline install looks like.
Images are exported with docker save on the connected side, carried across with a checksum, and loaded on the target host. The license is verified locally before the stack starts.
docker pull dataco/control-runtime:<version>
docker save dataco/control-runtime:<version> | gzip > dataco-runtime.tar.gz
sha256sum dataco-runtime.tar.gz > dataco-runtime.tar.gz.sha256
# also carry: license.json, license public key, config + policiesIllustrative example · final API surface documented in /docs
What happens as an offline license approaches its end date.
The license is an Ed25519-signed file checked against the local clock. Any edit to its contents invalidates the signature.
| State | When | Effect |
|---|---|---|
| Valid | Within term | Normal operation |
| Expiring | Shortly before the end date | Still enforcing; a signal to bring a renewal across |
| Grace | After the end date, for the grace period | Still enforcing; health reports degraded |
| Expired | After the grace period | Gateways refuse requests until a new license is loaded |
Signed policy bundles, so only your reviewers can change the rules.
Policies change more often than software. Across an air gap, the recommended path is a signed bundle: your team generates a signing key once and keeps the private half offline, signs a reviewed policy directory, and carries the bundle in. The runtime accepts only bundles signed by keys you trust, validates them in a staging area, runs the policy test suites, and swaps them in only if everything passes. The previous set is kept for rollback.
Audit integrity is verifiable offline too. Each record includes the hash of the one before it, so modifying, deleting, or reordering an entry breaks the chain, and a verification command checks the full set of segments without any outside service.
Questions buyers ask
How does licensing work without a connection?
Licenses are cryptographically signed files that Control verifies locally. They carry entitlements and term; renewal means bringing a new signed file across under your transfer procedure.
How do we get model updates?
New model versions are transferred like any release artifact: verified, reviewed, imported into the local mirror, registered, evaluated, and promoted through the registry.
Does anything report usage back to Data.co?
No. There is no telemetry in air-gapped deployments. Usage and health data stay in your local monitoring. If you need support, you decide what diagnostic data to export.
How is support provided?
Through documentation shipped with each release, scheduled calls, and diagnostic bundles you review and export. Where your program allows, cleared on-site support can be arranged under contract.
Is the air-gapped version missing features?
The core platform is the same. Features that depend on external services, such as external commercial model APIs or opt-in fleet administration, are unavailable by definition.
What stops the software from attempting an outbound connection?
Air-gapped mode disables external model endpoints and refuses the optional heartbeat even if configured, and an egress guard rejects any destination other than configured local endpoints. Most sites also mark the container network as internal so no route out exists.
Why does the time source matter?
License validity and audit timestamps both depend on the clock. An isolated network needs a trusted internal time source, or license states and log ordering become difficult to reason about.
Size it before you buy it.
An infrastructure assessment maps your workloads, data constraints, and existing hardware to a deployment model and a bill of materials you can review.