Canadian data residency
Stored in Canada, processed in Canada, and enforced by the database.
Most residency claims cover storage and go quiet about the AI. This page covers both, names the regions, and is explicit about the two places the claim does not reach.
Where the data actually sits.
Three services hold or touch customer data. All three run in Montréal, and each region below is a deployment setting rather than a policy statement.
| Layer | Service | Region |
|---|---|---|
| Application and APIEvery server route that touches workspace data is pinned to the Canadian region. | Vercel | yul1 · Montréal |
| Database, files, and authenticationFindings, evidence, uploaded documents, and the audit trail. | Supabase Postgres | ca-central-1 · Montréal |
| Audit workerThe service that loads your pages, runs the tests, and captures screenshots. | Google Cloud Run | northamerica-northeast1 · Montréal |
The AI is bring-your-own, which is why the claim holds.
limena sends page and document content to a model to explain findings and draft fixes. In a workspace, that model is always yours. We do not have a shared key on that path to fall back to.
CANChat
CanadaGovernment of Canada
Processes inside Government of Canada infrastructure.
Azure OpenAI
Your tenancyYour tenant, Canadian region
Text never leaves the subscription you already hold.
Self-hosted endpoint
Your tenancyAny OpenAI-compatible host
Processes wherever your operator put it, which is the point of offering it.
Anthropic or OpenAI, direct
United StatesThe vendor’s own hosted service
Refused by the database when the workspace holds a Canadian residency.
A Canadian workspace cannot hold a US model. The two settings are checked against each other when either one changes, and the mismatch is rejected with an error naming the provider and the region. This is a constraint in the database, so it applies to the API and the screens alike.
What makes it a control rather than a promise.
A setting that can be changed by anyone, at any time, without a record, is a preference. These three are what make it something you can put in front of a reviewer.
Chosen once, not toggled
Residency is set during onboarding and stated as permanent before the choice is made. It is not a preference someone can quietly change after procurement has seen it.
Refused, not warned
Pairing a US-processing model with a Canadian residency raises a database error and the change does not save. A screen can be bypassed by calling the API directly. The database cannot.
No shared key to fall back to
Every AI feature in a workspace uses your provider. With none configured the endpoints refuse the request rather than quietly using ours, because ours does not exist on that path.
Where the claim stops
Three things we will not let the word Canadian cover.
You are going to find these in a security review anyway. You should find them here first, from us, while you still have time to decide whether they matter.
Ask us directlyOur providers are US-incorporated
Vercel, Supabase, and Google operate the Canadian regions above, and all three are American companies. Your data is stored and processed in Canada. The corporate jurisdiction of the operator is a separate question, and if it matters to your assessment we would rather you weigh it than have the word Canadian cover both.
The free public scan is not covered
A scan run without an account has no workspace, so it has no residency setting to honour. It uses our own model key, which processes in the United States. It stores nothing and discards the result, but do not point it at anything sensitive.
We do not hold SOC 2 yet
Readiness work is underway and the first third-party penetration test is scheduled. We will publish dates when they are set rather than imply a report exists.
Send us the residency section of your questionnaire.
We will complete it against the running infrastructure, including the questions where the answer is not the one you were hoping for.