What Canadian data residency actually requires

“Where is our data?” has become one of the first questions in Canadian procurement, and the honest answer for most teams is more complicated than they would like.

This post covers what residency means in practice, and — just as importantly — what it does not.

Residency is about where bytes sit

Data residency is a physical claim: the servers holding your customer records are located within a particular country’s borders. It is verifiable and specific.

For a Railyard deployment, that claim covers your application servers — the containers, their attached databases, their volumes, their uploaded files. You choose the region when the server is created:

Provider	Region	Location
AWS	ca-central-1	Montréal, Québec
DigitalOcean	tor1	Toronto, Ontario
OVHcloud	bhs	Beauharnois, Québec

Pick one of those and your application’s data lives on a machine in Canada. Attach a machine in your own facility and it lives wherever that facility is.

Residency is not compliance

Here is the part vendors tend to skip. PIPEDA does not, in general, forbid processing data outside Canada. Québec’s Law 25 imposes assessment obligations for transfers rather than a flat prohibition. Several provincial health privacy acts are stricter and treat location as close to determinative.

Which means: residency is usually a necessary part of a compliance story and almost never a sufficient one. Access controls, retention, breach notification, and your agreements with sub-processors all sit alongside it.

If you are working toward a specific obligation, get counsel to review your particular setup. We will answer technical questions for that review, but the review has to happen.

The control plane question

One more distinction worth being clear about. Even when your application data is in Canada, a control plane holds operational metadata: server names, deploy history, audit entries, who pressed the button.

Two options:

• Hosted control plane. Railyard operates it, and it holds that metadata.
• Self-hosted control plane. You run it on your own infrastructure, in your own region, and no metadata leaves your environment at all.

For most teams the hosted plane is fine, because operational metadata is not customer data. For teams with strict obligations, self-hosting closes the question entirely.

A practical checklist

1. Create servers in a Canadian region and confirm it in your provider’s console.
2. Decide whether operational metadata needs to stay in Canada too.
3. Write down which sub-processors touch what, because you will be asked.
4. Have counsel confirm the arrangement meets the specific obligation you are working to.