Petrichor Labs hosts customer workloads in Canada, outside the reach of the US CLOUD Act. This note covers how I read the Act, how that turned into design rules for our stack, why we picked Canada, how we check vendors, and the limits of what we promise.
What the CLOUD Act says
The key clause is short. A provider subject to US jurisdiction has to produce data in its "possession, custody, or control" regardless of where that data is stored. The trigger is jurisdiction over the provider. It doesn't depend on the data being in the US or belonging to a US person.
Jurisdiction follows the provider's corporate reality: where it's incorporated, who owns it, where its staff and assets are. That's why a US-controlled hyperscaler's Canadian or European region doesn't solve the problem, even with a data-residency addendum. The data sits in Montreal or Frankfurt, but the company that can be ordered to hand it over is American. The addendum covers where data is stored, which isn't what the statute looks at.
Jurisdiction as a design input
Once I read it that way, jurisdiction became something we design for like any other requirement. For every part of the stack we ask who controls it and which courts can order them to act. That covers DNS, the CDN, observability, the support organisation and whoever can push firmware to our hardware.
If any layer with control over the system is US-controlled, the rest of the stack is reachable through it. In practice this meant running a lot ourselves that most teams would buy as a managed service. The private meshes note covers how we operate that. There are no US-controlled dependencies left in the stack.
Why Canada
Our customers needed to be outside CLOUD Act reach without leaving the North American legal and business context they already work in. Petrichor is Canadian-incorporated, Canadian-hosted and Canadian-staffed, which does that.
Canadian privacy law (PIPEDA and the provincial laws alongside it) is workable and has been tested in court. Latency to customers in Canada and the US is under 80 ms. And there's no entity in our corporate structure that a US order can attach to.
I didn't go looking for the most unusual jurisdiction available. Customers and their lawyers need to understand the legal regime their data sits under, and Canada is one they already deal with.
Checking vendors
Almost every infrastructure vendor now calls itself sovereign, so the label doesn't tell us much. We go layer by layer (hardware supply, network, control plane, support) and ask who controls it, whether they can be compelled, and in which courts.
If a vendor couldn't give a clear answer about who controls a layer, we didn't use them for that layer.
Limits and trade-offs
Petrichor is subject to Canadian law, like any company hosting data in Canada. Mutual legal assistance treaties between governments exist and work, on slower, court-supervised terms. What we claim is narrower and can be checked: no entity in our stack can be compelled under the CLOUD Act specifically, because none of them is subject to US jurisdiction.
There are costs. The hiring pool is smaller than in a US tech hub. We have fewer points of presence than a hyperscaler. And we have to keep checking new dependencies, because a convenient managed service can bring a US-controlled provider back into the stack without anyone noticing at the time.