Beyond the News
Sign in
Cloud & InfrastructureCloud PlatformsDatabases & Storage Active dossier

Cloudflare R2 adds a US-only data residency jurisdiction

Cloudflare R2 can now guarantee that bucket data is stored and processed within the United States, giving builders a hard residency control rather than a best-effort location hint—but the choice is fixed when the bucket is created.

Reviewed and published by Lars Jansen Updated 4 min read
First published

Key details

  1. Added August 17, 2026.
  2. The `us` jurisdiction guarantees R2 bucket data is stored and processed within the United States.
  3. US-jurisdiction S3 endpoint format is account-specific under `.us.r2.cloudflarestorage.com`.
  4. Workers R2 bindings can set `jurisdiction` to `us`.
  5. A bucket’s jurisdiction cannot be changed after creation.
  6. Location hints remain best-effort and are not equivalent to jurisdictional restrictions.

What builders should take away

  1. If US data residency is a contractual or regulatory requirement, use a jurisdictional bucket rather than relying on an R2 location hint.
  2. Plan the decision before bucket creation. Existing buckets that need the new guarantee require a data-migration path because jurisdiction cannot be changed in place.
  3. Audit the full data path: an R2 jurisdiction does not automatically make application compute, logs, databases or third-party services US-only.
  4. For S3-compatible clients and Workers, test endpoint/binding configuration in staging before migration so jurisdiction-specific addressing does not become a production cutover surprise.

What changed

On August 17, 2026, Cloudflare added a `us` jurisdiction to R2. Buckets created with it are guaranteed to have their data stored and processed within the United States. Access uses a jurisdiction-specific S3 endpoint or a Workers R2 binding configured with `jurisdiction: "us"`.

Why it matters

R2 previously offered location hints that influence placement but do not guarantee residency. A jurisdictional restriction changes the compliance story for SaaS products and data workloads that must keep object data inside the US. Because jurisdiction is selected at bucket creation and cannot be changed later, adopting it can require a migration rather than a configuration toggle.

A hard residency boundary, not a placement hint

Cloudflare distinguishes R2 location hints from jurisdictional restrictions. Hints are best-effort placement controls intended mainly for latency; jurisdictions are guarantees about where data is stored and processed. The new US option joins Cloudflare’s existing jurisdiction mechanisms for workloads that need explicit geographic constraints.

The operational cost is migration

Jurisdiction is immutable after bucket creation. Teams with existing unrestricted or differently constrained buckets must create a new US-jurisdiction bucket and move or rehydrate data if they need the guarantee. Applications also need to use the US-specific S3 endpoint, and Workers bindings must identify the jurisdiction explicitly.

What the guarantee does—and does not—cover

The R2 documentation describes the restriction in terms of bucket data being stored and processed within the selected jurisdiction. Builders should still map the rest of their architecture separately: application compute, logs, analytics, databases, third-party processors and client traffic may have different residency properties.

What to watch next

  • Whether Cloudflare adds more country-level R2 jurisdictions beyond the current set.
  • Migration tooling for moving existing buckets between unrestricted and jurisdiction-constrained storage.
  • Clarification or certification around how the US jurisdiction maps to specific compliance regimes and service commitments.
  • Whether related R2 features such as Data Catalog and R2 SQL expose equivalent jurisdiction guarantees across their full processing paths.

Still unclear

  • Cloudflare documents the storage-and-processing guarantee for R2 bucket data, but builders must evaluate separate Cloudflare and third-party services independently for end-to-end residency.
  • The changelog does not provide an in-place conversion mechanism for existing buckets; current documentation says jurisdiction is immutable after creation.

Sources

Direct reading behind this dossier.

3 sources
Data location
Cloudflare R2 Docs official documentation

Explains the distinction between best-effort location hints and jurisdictional restrictions that guarantee storage and processing location.

Snowflake regions for R2
Cloudflare R2 Docs official documentation

Current integration guidance reiterating that jurisdictions enforce where data is stored and processed, including US, EU and FedRAMP contexts.

Continue reading
Cloud & Infrastructure

Neon makes Functions and Object Storage branch with Postgres

Neon’s beta backend now combines Postgres branches with Node.js Functions and S3-compatible Object Storage that inherit branch semantics. For builders, that makes ephemeral preview/test environments more complete: database state, backend code and object data can move together instead of requiring separate production-adjacent services.