Enterprise
Data residency and region control
Residency as a deployment decision you control — from multi-region Ciao cloud to your own cloud account, private VPC, or on-prem under separate terms.
Data residency on Ciao is controlled by deployment choice. Ciao's infrastructure is built on Kubernetes with isolated pods and multi-region support, and applications can deploy to Ciao cloud, your own AWS, Azure or GCP account, a private VPC, or on-prem under separate terms. Unlike platforms with a single fixed region, teams with residency obligations can keep the application and its data inside infrastructure and regions they already govern.
Published 2026-07-03 · Last updated 2026-07-03
Residency is a deployment decision, not a checkbox
When a privacy or sector regulation says data must stay in a jurisdiction, the honest engineering question is: which system, which data, running where? A vendor answering 'we are compliant' without specifying where the application runs, where its data is stored and which subprocessors touch it has not answered anything your transfer-impact assessment can use. Residency deserves the same evidence standard as every other control on these pages: named locations, named options, and documents that state both.
Ciao's answer is structural. The platform runs on Kubernetes with isolated pods and multi-region support, and — more importantly for residency-sensitive programs — the application does not have to run on Ciao's cloud at all. Deployment into your own cloud account, a private VPC, or on-prem under separate terms puts the application and its data inside boundaries and regions you already control, monitor and answer for. The choice is per program, not per vendor relationship: a regulated workload can run in your own EU cloud account while less constrained teams use Ciao cloud, under one agreement and one governance model.
What Ciao provides
Residency control comes from five properties working together:
- Multi-region infrastructure — Infrastructure designed to scale — Kubernetes, isolated pods, hibernation and wake, multi-region support — so region options are an architectural property, not an afterthought.
- Deployment into your own cloud — Deploy to your own AWS, Azure or GCP account, in the regions your obligations require and your team already operates.
- Private VPC and on-prem — Available under separate terms, for programs whose analysis requires a private network boundary or their own data center.
- Model data handling — Customer code is not used to train models, and inference runs under zero-retention model contracts — the commitments that matter when reviewing model vendors as subprocessors.
- Exit without stranding data — 100% code ownership with export to your own repo at any time, so a residency decision is never locked in by the vendor.
Where data lives, honestly
The correct answer depends on the deployment option you choose, which is why this page gives you a table instead of a slogan. On Ciao cloud, region options are confirmed with the enterprise team during procurement. In your own cloud account or private VPC, the application and its data run in the regions you select and govern. On-prem, they run in your facility. In every posture, model inference is governed by zero-retention contracts, and the residency characteristics of model providers are reviewed as part of the subprocessor discussion.
Notice what this framing refuses to do: it does not claim a single answer for all customers, because there is not one. Residency posture is chosen per program, and the correct verification differs by posture — a table row, not a tagline. Ask any vendor the same question and insist on the same shape of answer.
Deployment options and where data runs
The honest answer to 'where does our data live?' is one of these four rows:
| Deployment option | Where the application and data run | Notes |
|---|---|---|
| Ciao cloud | Ciao-operated multi-region infrastructure | Region options confirmed during procurement |
| Your own AWS, Azure or GCP account | The regions you choose in your own account | Your cloud governance and monitoring apply |
| Private VPC | Your private network boundary | Available under separate terms |
| On-prem | Your own data center | Available under separate terms |
Choosing a residency posture
The sequence that keeps your obligations, not the vendor's menu, in charge:
1. Map the obligations
Identify which regulations and contracts constrain where each class of data may live — the requirements, not the vendor menu, come first.
2. Pick the deployment target
Match obligations to posture: Ciao cloud where flexibility suffices, your own cloud account or private VPC where region and boundary control matter, on-prem where nothing else passes review.
3. Confirm regions and subprocessors
During procurement, get region specifics and current subprocessor information — including model providers — in writing, not from a webpage.
4. Document it in the DPA
The Data Processing Agreement records data-handling commitments; your transfer analysis should reference the posture you actually chose.
5. Verify after deployment
In your own cloud account, your existing tooling verifies where things run; in every posture, the append-only audit trail records deploys and admin actions for later review.
Verification notes
Treat residency claims as procurement artifacts. Region specifics, subprocessor locations and data-flow detail belong in the security pack and the DPA — both available on request via the contact page — and SOC 2 Type II reports are available under NDA for the audited control environment behind them. If your program's residency requirement is strict, say so in the first conversation: the deployment options exist precisely so the platform can meet the requirement rather than argue with it.
For programs balancing residency against delivery speed, the practical pattern is to run the review once, document the approved posture, and reuse the decision across subsequent builds — later projects inherit the posture rather than re-litigating it.
Frequently asked questions
Can we keep all application data in the EU?
Deploying into your own AWS, Azure or GCP account in EU regions keeps the application and its data inside infrastructure and regions you govern. For Ciao cloud, confirm current region options with the enterprise team during procurement.
Where does model inference happen, and is anything retained?
Inference runs under zero-retention model contracts, and customer code is not used to train models. The residency characteristics of model providers are reviewed as subprocessors during the DPA and security-pack discussion.
Is the on-prem option suitable for isolated or restricted networks?
On-prem is available under separate terms, and the terms discussion is where network isolation requirements belong. Describe your constraints to the enterprise team rather than assuming a standard package fits.
Does multi-region support mean automatic failover between regions?
Multi-region support is an infrastructure property; the behavior for your specific deployment — regions, redundancy, recovery expectations — should be confirmed in writing during procurement and documented in your agreement rather than inferred from this page.
What happens to our data and applications if we leave?
You own the code — standard React, TypeScript and Tailwind, exportable to your own repo at any time — and in your-own-cloud, VPC and on-prem postures the data already lives in infrastructure you control. Exit terms are part of the agreement your legal team reviews.