Canada data region, and choosing your organization's region at setup

ReclaimLLM now supports Canada (ca-central-1) as a data region, alongside the United States and the European Union. When an enterprise admin creates an organization, they choose the region, and new sessions from every member are stored there. Individual users can also move their own data between any two regions, once.

What changed

• Canada is a third region. Session blobs for users and organizations set to Canada are stored in a Canadian bucket. Search metadata and the rest of your account data are unchanged by this release.
• Region choice at enterprise setup. The "Create Organization" page has a new Data region field. It lists the regions the deployment has storage for.
• Members follow the org. When someone joins the organization, their new sessions go to the org's region. Sessions they captured earlier stay where they are.
• Any region to any region, once. In Settings → Data Residency, a user can switch to any other available region. Existing sessions are copied to the new region in the background and the originals are deleted afterwards. The change can be made one time per account.

Choosing a region when you create an org

The choice at setup is free. It does not use up your one-time region change, because no organization data exists yet. The region is stored on the organization and applied to your account, so everything you capture from that point lands in the chosen region.

Members who join later by invite get the same treatment: their account's region is set to the org's, and their new sessions follow. Members of an organization with a region can't change their own region. The Data Residency settings page tells them the organization manages it. We did this on purpose: if a member could move their data out, the organization's choice wouldn't mean much.

Organizations created before this release have no region set. Their members keep whatever region they already had. There is currently no way to set or change the region of an existing organization.

Moving your own data

For individual accounts, the Data Residency page offers every region other than your current one. Switching:

1. Applies the new region straight away, so new sessions go there from that moment.
2. Starts a background migration that copies each older session to the new region, updates its location, then removes the original.
3. Shows progress, and a retry button if more than a small fraction of sessions failed.

Each session is moved from the region it is actually in. A single account whose sessions are split across regions, for example after an interrupted move, ends up in one place after a retry. You get one change. After a migration completes the option is gone, so check the target before confirming.

What this does not cover yet

We would rather list these than have you find them:

• Two enterprise code paths still use US storage. Cleanup of sessions created through the gateway, and the files generated by dataset model-analysis exports, don't yet pick the storage region from the session or organization. If you depend on those, treat them as not yet region-aware.
• Org region is applied when members join, not checked on every upload. If an account's region is changed some other way after joining, new sessions will follow the account, not the org. We think this is a narrow gap, but it is a gap.
• No org-level migration. Setting a region at creation covers new data. Moving an organization's existing data as a group is not built.
• Self-hosted deployments map every region to the storage you configure, so regions there are labels, not separate locations.

Why we built it this way

Region was already a per-account setting that every upload path reads. Making the organization's choice set that value at creation and at join meant no ingest path had to change, which kept the risk low. The cost is the gap above: the guarantee comes from setup-time assignment, not from enforcement at upload.

We made Canada fail closed. If the Canadian storage isn't configured in a deployment, requests for it return an error instead of quietly falling back to US storage, because a silent fallback would defeat the point of choosing a region.

The one-time rule is deliberately strict. Copying and deleting blobs is the part most likely to go wrong, and a single allowed change keeps the number of partial states small.

Feedback

If you run into a case where a session ended up in the wrong region, a migration that doesn't finish, or a workflow where you need to set or change an organization's region after the fact, tell us. Those reports will decide what we build next, and we want to hear about the ones we got wrong.