Open app
Moonborn — Developers

Data residency config

Pin org data to US or EU at signup. Verify residency, understand cross-region read prevention, plan a migration when business requirements change.

Moonborn is regionalized at the org boundary: US and EU. The region is picked at signup and locked thereafter (ADR 0011). All persistent data — personas, chat transcripts, audit log, embeddings, billing records — stays in the chosen region.

Verify your region

const org = await client.organizations.getCurrent();
console.log(org.region); // "us" | "eu"

The region is also visible in Settings → Organization → Region.

Cross-region reads

Cross-region reads are blocked at the database boundary — not a policy check, a physical isolation. An EU-region API key cannot read US data even with the right RBAC; the request returns 403 cross_region_blocked.

This means:

  • Your EU users never share infrastructure with US data.
  • A US admin cannot accidentally pull EU records into their dashboard.
  • Subprocessors in one region don't carry data from the other.

Compliance posture

RequirementRegion
GDPR (EU residency)EU
US HIPAA BAAUS
Customer in both?One org per region

Migration

Region change is not supported in-flight. To migrate:

  1. Export from current region: 
    await client.privacy.requestDsarExport({ orgId: oldOrg.id });
  2. Sign up a fresh org in the target region.
  3. Import the export into the new org: 
    await client.privacy.importExport({ archive });
  4. Update SSO / SCIM endpoints to point at the new org.
  5. Decommission the old org once verified.

ADR 0011 explains the design: in-flight migration would require complex consistency reasoning across regions and break the "region is a property of the org" invariant.

Tier

US/EU choice: every tier (default US). Region lock: enforced for every tier. EU-residency contractual guarantees: Enterprise.

Related