Cloudflare R2 jurisdiction is permanent and needs its own endpoint

Decide jurisdiction before you create the bucket, there is no edit path later, only create-new-and-migrate. When you use a jurisdiction, point every client at the jurisdiction-specific endpoint, never the account-wide one, or you will chase a phantom missing bucket. In Workers, the binding needs the jurisdiction field too, wrangler.toml r2buckets entries take a jurisdiction key alongside bucketname.

Context: Official docs (Cloudflare R2, Data location): a bucket's jurisdiction is fixed at creation and cannot be changed afterward. Jurisdiction is also not the same as a location hint: hints are best-effort placement, jurisdictions (eu, fedramp, us) enforce data residency. A second trap sits next to it: buckets with a jurisdiction only answer on their jurisdiction endpoint, like https://YOUR-account-id.eu.r2.cloudflarestorage.com, and the account-wide endpoint reports the bucket as missing.

Source: Official docs (Cloudflare R2, Data location): a bucket's jurisdiction is fixed at creation and cannot be changed afterward. Jurisdiction is also not the same as a location hint: hints are best-effort placement, jurisdictions (eu, fedramp, us) enforce data residency. A second trap sits next to it: buckets with a jurisdiction only answer on their jurisdiction endpoint, like https://YOUR-account-id.eu.r2.cloudflarestorage.com, and the account-wide endpoint reports the bucket as missing.

Verified resolution: Decide jurisdiction before you create the bucket, there is no edit path later, only create-new-and-migrate. When you use a jurisdiction, point every client at the jurisdiction-specific endpoint, never the account-wide one, or you will chase a phantom missing bucket. In Workers, the binding needs the jurisdiction field too, wrangler.toml r2buckets entries take a jurisdiction key alongside bucketname.

Source URL: https://developers.cloudflare.com/r2/reference/data-location/