Dedicated cloud capacity, with no shared AI layer.
A private cloud deployment gives you a single-tenant environment in a region you choose: your own GPU capacity, your own databases and indexes, and your own Control instance. Nothing in the AI path is shared with another customer.
When you need the boundary but not the building.
Not every organization has data center space, power for GPU servers, or appetite for hardware lifecycle management. A private cloud deployment keeps the isolation properties that matter, dedicated compute and storage, keys you control, and a network you define, while moving facilities work to a provider.
Single-tenant matters specifically for AI. Shared inference services can mean shared GPUs, shared caches, and shared logging pipelines. In this model, every component that touches prompts, documents, or embeddings is dedicated to you.
Where the environment can live.
| Option | Account ownership | Good fit when |
|---|---|---|
| Your cloud account | You | You have an existing cloud landing zone and GPU quota |
| Dedicated servers hosted by Data.co | Data.co, single-tenant | You want reserved hardware without owning a facility |
| Provider's sovereign or regional offering | You | Residency rules require a specific jurisdiction |
What single-tenant covers.
Compute
GPU and CPU capacity dedicated to your environment, not pooled with other tenants.
Data stores
Your own PostgreSQL, pgvector indexes, and object storage, encrypted with keys you control.
Network
Private connectivity to your sites; public exposure only where you decide.
Control plane
Your own Control instance, policies, and audit log, not a shared multi-tenant service.
Standing up a private cloud environment.
- 1
Choose region and account
Confirm residency requirements and whether the environment lives in your account or on dedicated servers.
- 2
Confirm GPU capacity
GPU availability varies by region and provider; we confirm it against your sizing before committing.
- 3
Connect privately
Set up private connectivity to your identity provider and source systems.
- 4
Deploy and govern
Install Control, register models, apply policies, and validate with a pilot group.
Controls to verify in the account itself.
Single-tenant compute is only part of the boundary. These account-level settings decide whether it holds.
- No public IP addresses on GPU or database instances
- Egress restricted to the endpoints the deployment actually needs
- Disk, snapshot, and object storage encrypted with keys you manage
- Instance metadata service locked down against credential theft
- Separate cloud roles for infrastructure operators and data owners
- Flow logs and control-plane audit logs exported to your SIEM
- Snapshots and backups excluded from cross-account sharing
- Model weight buckets private and versioned
GPU capacity behaves differently from ordinary cloud compute.
Elastic scaling assumes instances are easy to get and quick to start. Large GPU instances are often neither. Capacity in a given region can be constrained, and a large model can take minutes to load before a new node serves its first request. Many private AI deployments therefore run a steady reserved baseline sized for normal demand, and treat additional capacity as planned rather than automatic.
Idle GPUs are expensive, so the usual levers are workload placement, not scale-to-zero: consolidate smaller models onto shared GPUs, schedule batch work into quieter hours, and use gateway quotas to stop one application from forcing a capacity purchase. The assessment models these options against your usage profile so the reservation is neither oversized nor brittle.
Questions buyers ask
Is this the same as using a hosted model API?
No. Hosted APIs process your prompts on shared provider infrastructure. Here, models run on dedicated capacity in an environment that only serves you, governed by your own Control instance.
Who holds the encryption keys?
You can use keys you manage in your cloud account's key management service. Specific options depend on the provider and region.
Can sensitive data stay on-prem while models run in the cloud?
That is a hybrid design. It is possible, with policies controlling what may leave the on-prem boundary; see the hybrid deployment page for the trade-offs.
What about GPU availability?
GPU capacity varies by provider, region, and time. We check availability against your sizing during the assessment, and dedicated servers are an option when cloud capacity is hard to reserve.
Does the cloud provider see our prompts?
The provider operates the underlying hardware and hypervisor, as with any cloud workload, but no provider AI service is in the path. Inference runs on your instances, and prompts are not sent to a hosted model API unless a policy explicitly allows one.
Can the environment be built with infrastructure as code?
Yes, and we recommend it. Defining networks, instances, and key policies in your existing tooling makes the environment reviewable and reproducible, and makes a second region or a rebuild a repeatable exercise.
How do users reach the environment?
Usually through private connectivity from your corporate network, with the gateway exposed only on private addresses. Public exposure, if any, is a decision you make and document, not a default.
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.