Pick the boundary first. Then pick the hardware.
Data.co Control runs the same way in your data center, a single-tenant private cloud, a hybrid of the two, or a fully disconnected network. We help you choose the deployment model your data requires, then size and supply the hardware to run it.
Four ways to run Control, compared plainly.
The software is the same in every model. What changes is who owns the hardware, where the network boundary sits, and how updates arrive.
| On-premises | Private cloud | Hybrid | Air-gapped | |
|---|---|---|---|---|
| Hardware owner | You | Single-tenant, dedicated to you | Mixed | You |
| Where data lives | Your facility | Dedicated environment in a chosen region | Sensitive data stays local | Inside the isolated network |
| Internet required | No, optional for updates | Provider connectivity | Link between sites | None |
| Licensing | Online or offline | Online | Online | Offline signed licenses |
| Updates arrive via | Registry mirror or media | Registry | Registry | Signed offline media |
| Typical driver | Existing data center, strict residency | No facility capacity | Burst compute, local records | Classified or isolated networks |
The machines that run it.
GPU servers
Multi-GPU nodes for production inference and fine-tuning.
AI workstations
Single-user or small-team machines for pilots, labs, and local model work.
Private AI appliances
Pre-configured, rack-ready nodes with Control installed and validated before delivery.
Dedicated servers
Reserved hardware that Data.co hosts and manages for you, single-tenant.
Procurement
Sourcing, burn-in, staging, and delivery so hardware arrives ready to join the cluster.
Assessments
Workload sizing before purchase, so you buy for the models and concurrency you need.
Moving between models is a migration, not a rewrite.
Policies, model registry entries, connector configurations, and audit schemas are portable across deployment models. A team that starts on a workstation pilot can move to on-prem GPU servers, or add a private cloud region, without rewriting policies or applications.
In every model, app.data.co only handles accounts, licensing, billing, and opt-in fleet administration. It never receives prompts, documents, embeddings, or records, and in air-gapped deployments it is not contacted at all.
From constraints to a running environment.
- 1
Assess
Document workloads, data classifications, network constraints, and existing hardware.
- 2
Design
Choose the deployment model and produce a sizing plan and architecture you can review.
- 3
Supply
Use your hardware, procure through us, or reserve dedicated servers we host.
- 4
Operate
Run it yourself with our documentation, or under a managed services contract.
Questions that usually settle the deployment model.
Answer these with your security, legal, and facilities teams in the room. The answers tend to point to one model before anyone discusses hardware.
- Must any of the data stay within a specific facility or jurisdiction?
- Is the target network allowed any outbound connectivity at all?
- Do you have rack space, power, and cooling for high-density GPU nodes?
- Is demand steady, or does it spike around batch jobs and deadlines?
- Who will patch drivers, rotate certificates, and respond at night?
- How quickly do you need capacity, given current hardware lead times?
- Which workloads could move later, and which never can?
The same runtime, wherever it lands.
Every deployment centers on the Control runtime: a container that hosts the OpenAI-compatible AI gateway and the MCP gateway, evaluates policies locally, and appends every decision to a hash-chained audit log. It runs as an unprivileged user with a read-only root filesystem. Around it sit the model servers, PostgreSQL with pgvector for retrieval, connectors to your sources, and your existing identity provider and monitoring.
The runtime opens outbound connections only to the model endpoints and tool servers you configure; an egress guard rejects any other destination before a socket is opened. The license is a signed file verified offline. That is why the same build can sit in a cloud account, a hospital data center, or a disconnected enclave: the differences are in how artifacts arrive and who operates the hardware, not in how enforcement works.
Who typically does what.
A starting point for a responsibility matrix. Managed services can shift most operational rows to Data.co under contract.
| Activity | Self-operated | With managed services |
|---|---|---|
| Facility, power, cooling | You or your hosting provider | Unchanged, or Data.co for dedicated servers |
| OS, drivers, firmware patching | Your infrastructure team | Data.co, in agreed change windows |
| Runtime and model upgrades | Your platform team | Data.co, with your approval |
| Policies and approvals | Your security and data owners | Still yours; Data.co can draft |
| Audit review and retention | Your security team | Still yours |
Questions buyers ask
Which deployment model do most organizations choose?
It depends on constraints rather than preference. Organizations with existing data centers and strict residency often choose on-prem; those without facility capacity choose private cloud; regulated environments with classified networks choose air-gapped. An assessment makes the trade-offs specific to you.
Is the product different in an air-gapped deployment?
The software is the same. The differences are operational: offline signed licenses, updates delivered on signed media, and no telemetry or fleet administration connection.
Can we use hardware we already have?
Often. The assessment checks existing servers and GPUs against your workloads and recommends additions only where needed.
Do we have to buy hardware from Data.co?
No. You can supply your own, procure through us, or use dedicated servers we host. Procurement is offered for teams that want staging and validation handled before delivery.
Can different business units use different deployment models?
Yes. A research group might run on dedicated servers while a clinical unit stays on-prem. Each deployment has its own license and runtime, and policies written once can be applied to both.
What has to be backed up in every deployment?
The audit log segments and approvals state, the policy files, PostgreSQL including vector indexes, the model registry metadata, and your artifact mirror. Model weights can be restored from the mirror rather than re-downloaded.
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.