Durable Objects Add Regional Data Controls

Cloudflare has extended its Durable Objects platform with Jurisdictional Restrictions, a feature that lets developers pin a specific object's storage and processing to a defined geographical region. The capability is aimed at teams building stateful applications on Workers who must satisfy data localization rules without running separate infrastructure per region.

Durable Objects, currently in invite-only limited beta, abstract away the provisioning of stateful backends for Workers applications. With Jurisdictional Restrictions, developers can now enforce that a given object never leaves a designated region, making it simpler to partition data by user location or regulatory requirement while keeping the application globally accessible.

Encoding Region at ID Creation

Each Durable Object gets a unique ID that a Worker uses to communicate with it. That ID carries metadata for the Workers runtime, including a mapping to a specific Cloudflare data center. The selected data center handles object creation and keeps a routing entry so Workers can still reach the object if it migrates.

A developer creating an object for an EU data subject can generate an ID that hard-codes an EU-only restriction:

async function handle(request) {
    let objectId = USERS.newUniqueId();
    let user = await USERS.get(objectId);
}
async function handle(request) {
    let objectId = USERS.newUniqueId({jurisdiction: "eu"});
    let user = await USERS.get(objectId);
}

Jurisdictional Restrictions require no servers to spin up or databases to maintain. Adding support for a new set of regional rules is just a matter of passing a different string when generating an ID.

Scope and Current Limitations

Today the feature supports only the EU jurisdiction, with additional regions planned based on developer demand. Restrictions are applied per object, not per application or account, so a single deployment can route different users' objects to different jurisdictions as needed.

The per-object model also means developers no longer need to run multiple clusters of infrastructure across cloud provider regions for compliance. Durable Objects remain globally accessible while state is partitioned at the object level without added operational overhead.

Future work includes migrating objects between jurisdictions, which would let developers adapt to changing regulations after an object has been created.

How ID Generation Handles Restrictions

Durable Objects support two ID modes. With system-generated IDs, the runtime constructs an ID that maps to a data center near the Worker that created it. With user-generated IDs, the developer passes an identifier that is used as a seed for the placement decision.

When a Jurisdictional Restriction is applied to a system-generated ID, the runtime instead encodes a mapping to a jurisdiction that expands to a list of qualifying data centers. The data center chosen to create the object is guaranteed to be on that list, and the object will never migrate to a data center outside of it. For the eu jurisdiction, that list currently maps to Cloudflare's data centers in the EU.

User-generated IDs are a different case. Because requests may come from anywhere in the world and must locate an object deterministically without coordination, the ID must be derived solely from the user-provided string. That means jurisdictional restrictions cannot be encoded into a user-generated ID, and the two features are currently incompatible.

Requests for beta access are open to teams interested in using Durable Objects for compliance-focused workloads.