Intramedial is in restricted beta. At sign up or sign in, you have to provide the beta tester password you received or request one at preview@intramedial.com. Thank you.
Loading…
Data regions
Residency
Your records live where you put them.
Every workspace has one data region, chosen when it is created. Coordination records, leases and the ledger are stored there: the three European regions inside Cloudflare's EU jurisdiction, the others by location hint. Compute runs at the nearest edge. This page says exactly what is pinned, what is not, and what a region does and does not promise. Where something is not known, this page says so instead of guessing, and it makes no promise beyond the documents named below.
Agents act when the plane says yes, and the record says why.
Put admission in front of your MCP servers, repositories, SaaS tools and cloud accounts. Every agent gets a lease or a reason – and you keep the lever to stop any of them.
Each region is its own set of workers, its own database and its own object storage. Pins mark an area, not a building. The three European regions are pinned by jurisdiction; the others are placed with a hint.
Region
Code
Host prefix · where the service runs
Cloudflare code
Storage
US WestPrimary region
wnam
Oregon
WNAM
Location hint
US East
enam
N. Virginia
ENAM
The three European regions store data under Cloudflare's EU jurisdiction: Cloudflare keeps it inside the EU but chooses the datacenter, and a Cloudflare database cannot be pinned to a named city. What differs between the three is the service that handles your calls, which runs near Frankfurt, Ireland or Stockholm, and the key that signs your bundles: each region has its own. For the other four the database is created with a location hint, which is a placement request, not a guarantee. The European regions share the eu. address; the region of an account is recorded behind it.
Cloudflare's own description of D1 jurisdictions and location hints, as of October 2026: Cloudflare D1 data location ↗
02
Data scope
What stays in the region, and what does not.
The data plane is mirrored per region: each region has its own copy of the workers that hold customer content. The operator planes and billing are single. Compute runs at the nearest Cloudflare location to the caller, wherever that is.
Regional: in the region you chose
Leases, ledger rows and the policy store, kept
Durable Objects, pinned for EU-bound workspaces here
Connector secrets, in D1.
Scheduled jobs, storage and Tops chain workers, one full set in every region
03
Routing
How a request reaches your region.
Each region has its own API host. It forwards a request to that region's workers, which read and write only that region's database, and the region is set per workspace.
1Your agentA client or an agent, with a workspace key.
2
04
Signing keys
Each jurisdiction has a signing key.
Ledger bundles are signed with an Ed25519 key provisioned for a jurisdiction. The private key is a Worker secret, never exposed; the public half is meant to be published as a key set, and each entry names its jurisdiction.
Published, with its jurisdiction
The public half of each key is meant for one JWK set, and each entry names its jurisdiction. A bundle names its signer in signingKeyId. Live serving is not confirmed.
Shared by every workspace in the region
A key belongs to a jurisdiction, not to a workspace. Bundles of every workspace sealed there are signed with it.
05
Cross-region
What crosses regions.
Four kinds of data or traffic leave a region, and each is listed here. Nothing moves unless you rehome.
Between regions
Nothing
One region's workers read only their own database. Rehoming is the exception: it copies a snapshot.
Singles
Operators, billing
The operator planes are single and billing runs in US West. Neither is mirrored in every region at all.
06
Assignment
How a workspace gets its region.
You pick the region when you create the workspace. One account can hold workspaces in several regions.
At sign-up
The form preselects the region nearest your location, and lets you change it to another.
Every later workspace
The workspace-create form has the same picker, so a team can keep its EU work apart.
07
Performance
Latency
Work is done close to the data, but every request travels through the region's API host first. We have not published latency figures for any region and do not state any here.
The path of a call
Caller
Nearest Cloudflare location
API host
Regional workers
08
References
The documents behind a region
This page explains. These documents bind. If a regulator or a customer needs a contractual statement about where data is, they are the ones to read.
Billing and operator planes: Billing, in US West; the operator planes are single
Schematic map. Coastlines are simplified; a pin marks the area of a region, not a datacenter.
Location hint
Europe Central
weur-1
eu.Frankfurt
WEUR-1
EU jurisdiction, enforced
Europe West
weur-2
eu.Ireland
WEUR-2
EU jurisdiction, enforced
Europe North
neur
eu.Stockholm
NEUR
EU jurisdiction, enforced
Asia-Pacific
apac
asia.Singapore
APAC
Location hint
Oceania
oc
oc.Sydney
OC
Location hint
Bundle signing, with a key per jurisdiction
ActionFlow, Connectors, Portmind and OneMCP workers
Single, or not pinned here
Control Plane and Provider Admin
Sign-in through Avonao ID, whose location this page does not state
Billing, running in US West with Avonao Billing
KV, Queues and Workers AI, unpinned, with no customer content
Compute, which runs at the nearest edge
The public site and docs
What a region does and does not promise
A region says where data is stored. For the three European regions that is enforced by Cloudflare's EU jurisdiction. It does not say traffic never leaves a network edge: Cloudflare accepts a connection at the nearest location, and compute is edge-local unless Regional Services is bought, which we have not done. US East, US West, Asia-Pacific and Oceania are location hints only. For a contractual statement, read the Data Processing Addendum and the Privacy Policy.
3Region API hostsOne host per region, such as eu.api, which hands the request on to workers.
4Your region's workersAdmit or refuse the request and write to the ledger.Signed with the jurisdiction's keyStored in the region's database
Four rules worth knowing
01
The EU is pinned
Once the region is live in production, a request for an EU-bound workspace that reaches another region is refused with a 421. Local development is exempt, so test the pin on a live region.
02
Rehoming copies
It copies a snapshot the target pulls. Nothing is deleted at the source then.
03
Key choice shows
The signer prefers the region's key but may fall back to another. The bundle names it.
04
Verifying needs no region
Checking a bundle is public-key cryptography over the bytes you hold. It needs no account, no region and no call to us.
What your client may see
503
federation_unavailableA route points at a service that has no binding; nothing was processed.
421
Misdirected RequestThe EU pin: the request reached the wrong region.
503
Service UnavailableNo signing key is provisioned here, so no bundle is made at all.
Scheduled work is regional too
Cron, Tops and storage workers run in every region, over that region's own database. So a scheduled job is run from, and writes to, the region it belongs to. Status probes are not described here at all: status is not published yet, and none is claimed for it today.
rehoming.plan names a source and a target region and returns what would move and whether the target is EU-bound. Execute captures a snapshot; the target applies it on its next request.
What it does
Plan names the pinned Durable Object classes and whether the move is EU-bound. Execute copies leases, rows and object state.
What it does not do
It is not an atomic move and deletes nothing at the source. The snapshot is not signed, and the move is not written to the ledger that ledger.blame reads. There is no restore action.
Compute runs at the nearest Cloudflare location, which can be outside the region. Stored data stays in the region.
To your destinations
What you relay
An admitted action reaches the system you named, wherever it is, and leaves Cloudflare's network from the region that handles it. Where that system stores data is outside our control.
Later, it can move
Rehoming plans a move and copies a snapshot to the target region, which applies it on its next request. The source is not deleted at that moment, and the move is not signed.
Check the rehoming status
GET /api/v1/acp/rehoming/status returns the stored plan, so you can see what was planned and where.
Need EU residency?
Choose Europe Central, Europe West or Europe North. All three create their database and object storage under Cloudflare's EU jurisdiction. Compute still runs at the nearest edge unless Regional Services is bought, and we have not bought it yet.
The preselected region, by location
Only a default for the sign-up form, read from the request's country. You can always choose another.
If you sign up from
Preselected
Central and eastern Europe, the Balkans and the rest of the EU, the EEA and Switzerland; other European countries use the same default
Europe Centralweur-1
The British Isles, France, the Benelux, Iberia, Italy and Iceland
Europe Westweur-2
The Nordics and the Baltics
Europe Northneur
The Americas and Africa, and any visitor whose country cannot be read from the request at all
US Westwnam
Asia/ME
Asia-Pacificapac
Australia, New Zealand and the Pacific islands
Oceaniaoc
When the country cannot be read at all, the form preselects US West.
Regional database
Measure from your own network with your own client. We publish no latency numbers, and the status page has no data yet. Status page, later →
Residency
