Region pinning enforced
Pin a workspace, and the keys within it, to a region — eu-central, us-east or ap-southeast. The choice is validated at write time, so a key can never point at a region that does not exist or that its workspace does not allow.
Control Mechanisms / Residency
Pinned, and you can't silently widen it.
Pin a workspace or a single key to a region, and the platform holds you to it: the choice is
validated when you set it, immutable and expand-only once keys exist, and resolved on
every request rather than trusted from a config file. Residency here is an enforced policy,
not a checkbox that hopes for the best.
region: eu-central · us-east · ap-southeast lock: immutable, expand-only Swarm phase Coordination, not flow: residency is a boundary the data is pinned within — set once, only ever widened.
The policy
A boundary you set once and cannot quietly move.
Residency is not a label attached after the fact. A region is validated when a workspace or key is created, locked so it cannot be narrowed or relocated, and stamped onto every request as it is served. The controls below are enforced today on the path that answers the request.
Immutable & expand-only enforced
Once a workspace owns keys, its residency cannot be silently narrowed or moved — it can only ever be widened. You cannot quietly relocate where data may live, and a key’s region is written once and only broadened, never swapped underneath you.
Per-request attribution enforced
Every request is stamped with its region and carries a region-prefixed shard key end to end, so residency is resolved and recorded on the hot path — not reconstructed after the fact from a log.
Said plainly rolling out
Policy today, physical regions next.
What is enforced today is the residency policy: the region is validated, immutable, expand-only, and attributed on every request. What is not yet true is separate physical infrastructure per region — swarmsDB runs on a single backend today, so we do not claim your bytes physically never leave a region. Per-region physical deployment is the next milestone; until it lands, we describe residency as the enforced policy it actually is.
Stated precisely, because residency is exactly the claim a serious buyer will test: the pinning, the immutability and the attribution are real and enforced now. Physical per-region isolation is rolling out — we would rather tell you that than imply a guarantee the infrastructure does not yet make.
More in this area
Built for agentsWhy an autonomous agent runs leaner here — less context, typed data, a brake.Typed sectionsProject the fields you need — only those cross the wire.Bulk & scheduled fan-outOne call across many parameter sets — results by signed webhook.MCP & RESTConnect an agent over MCP, or call the REST surface directly.Keyless OAuth connectorsA third party connects by grant. No API key changes hands.Org controls chainThe enforced chain — org → workspace → api_key — members configure it, the backend holds it on the serving path.Members & workspacesTwo levels of role — org and workspace — enforced on the write path.Keys & restrictionsScope a key to the providers, rate, origins and region it may use.
Point one agent at it.
Connect over MCP or REST. If your agents read more than one source, the context bill is the first thing you will see move.