Keep Durable Objects in the US: Cloudflare Adds a `us` Jurisdiction

Cloudflare has added a us jurisdiction for Durable Objects. Confidence level: confirmed. Developers can now create Durable Objects that run and store persistent state inside the United States, while Workers elsewhere can still call those objects.

What changed

Cloudflare published the change on June 26, 2026. Durable Objects already supported jurisdictional restrictions; the new part is a United States jurisdiction alongside existing options such as eu and fedramp.

The implementation uses a restricted namespace:

const usSubnamespace = env.MY_DURABLE_OBJECT.jurisdiction("us");
const stub = usSubnamespace.getByName("general");

Cloudflare’s docs are precise about the boundary. The jurisdiction controls where the Durable Object itself runs and persists data. It does not mean requests can only originate from that region, and Workers may still access a US-restricted object from other places.

Key takeaways

• Durable Objects now list us as a supported jurisdiction.
• The feature targets compute and persistent storage location, not global request routing.
• Cloudflare recommends using DurableObjectNamespace.jurisdiction() rather than mixing jurisdiction rules into individual IDs.
• Data-location docs note that Durable Object IDs may still be logged outside the specified jurisdiction for billing and debugging.
• Teams should treat this as one compliance control, not a full data-governance program.

Availability and access

The changelog presents the feature as available now for Durable Objects. The reference docs list eu, us, and fedramp as supported jurisdiction parameters.

Before using it in regulated workflows, confirm plan eligibility, any Enterprise requirements around data localization, and how adjacent services handle logs, analytics, queues, object storage, and backups. A Durable Object can keep its own compute and storage inside the US while other parts of the application still create data elsewhere.

Practical LinkLoot angle

This is useful for teams that like Workers but have avoided stateful edge patterns because residency controls were too coarse. You can now separate application routing from state placement more cleanly: run a global Worker, then route sensitive state to a US-restricted Durable Object.

For agent builders, this matters when an AI workflow stores task state, customer context, approvals, or audit trails. It pairs naturally with the operational patterns in LinkLoot’s automation hub: /guides/ai-workflow-automation.

What to verify before you act

• Confirm the us jurisdiction is available in your Cloudflare account and deployment environment.
• Audit every connected service, not only the Durable Object.
• Decide whether callers also need Regional Services or another request-processing control.
• Test object creation paths so old objects do not remain in the wrong jurisdiction.
• Document logging, billing, and debugging exceptions before promising strict residency to customers.

Source check

Confirmed by: Cloudflare’s changelog announces the us jurisdiction, and Cloudflare’s Durable Objects data-location docs list us as a supported jurisdiction. Cloudflare’s earlier background post explains the jurisdictional restriction model behind Durable Objects.

Independent context: Modern Workspace Pro summarized the update on June 27, 2026 and repeated the same operational limitation: the jurisdiction controls where the object runs and persists data, not where Workers may call it from.