On this page · 11 sections
- What actually shipped on 13 August
- The conflict: namespaces create themselves, and self-created namespaces are unrestricted
- Wrangler cannot set a jurisdiction, but it can create the namespace
- The hostname tells you nothing
- What the docs do not say
- Pricing has not been restated for jurisdictions
- What to do this week
- India-specific considerations
- FAQ
- How eCorpIT can help
- References
Summary. Cloudflare shipped data localization for Artifacts on 13 August 2026, letting you pin a namespace to the European Union or the United States. Two jurisdictions, not three: R2 has offered eu, fedramp and us since before this, and its data location page was last updated on 19 August 2026 with FedRAMP still listed. The Artifacts control is set once, at namespace creation, and the docs state plainly that it "cannot be changed after creation". The problem sits one page over. The Artifacts namespaces page, updated the same day, says a repo created under a namespace name that does not exist causes Artifacts to create that namespace automatically. Auto-created namespaces get no jurisdiction, and they can never get one. Wrangler makes this worse: the wrangler artifacts command surface has namespaces list and namespaces get but no namespaces create, and the page carries zero occurrences of the word jurisdiction against a last-updated date of 18 May 2026. Artifacts bills at $0.15 per additional 1,000 operations and $0.50 per additional GB-mo on Workers Paid, and is unavailable on Workers Free.
What actually shipped on 13 August
The changelog entry, Data localization support for Artifacts, carries a dateModified of 2026-08-13 in its embedded JSON-LD. It says Artifacts "now supports jurisdictions, allowing you to select the European Union or the United States as the only location where repo data is stored and processed", and that you "Select a jurisdiction when you create a namespace".
The Artifacts data localization guide publishes the supported set as a two-row table: eu for European Union, us for United States. The REST API reference is tighter still, and it is the version worth reading, because it is typed:
export type Jurisdiction = "eu" | "us";
The create-namespace route is POST /artifacts/namespaces, and its body takes namespace (required) plus jurisdiction (optional, "default: unrestricted"). The reference then states: "The jurisdiction applies to every repo in the namespace and cannot be changed after creation. If you omit jurisdiction, Artifacts creates an unrestricted namespace."
Three sentences, and every failure mode in this article follows from them.
The conflict: namespaces create themselves, and self-created namespaces are unrestricted
The Artifacts namespaces concept page, last updated 13 August 2026, the same day as the localization feature, says: "You can create a namespace explicitly or let Artifacts create one automatically. If you create a repo under a namespace name that does not exist, Artifacts creates the namespace automatically."
Now put the two pages side by side. Jurisdiction is only settable on the explicit POST /artifacts/namespaces call. The create-repo route, POST /artifacts/namespaces/:namespace/repos, accepts exactly four body fields: name, description, default_branch and read_only. There is no jurisdiction field on it. So any path that reaches Artifacts through repo creation rather than namespace creation produces an unrestricted namespace, and the immutability rule means that namespace can never be corrected.
The realistic trigger is not exotic. It is a typo. Push to prod-eu when the governed namespace is prod_eu, or let a CI job template a namespace name from a branch, and Artifacts will helpfully create the new namespace and accept the data. Nothing errors. Nothing warns. The repo works.
| Behaviour | Explicit namespace create | Repo create under unknown namespace |
|---|---|---|
| Route | POST /artifacts/namespaces |
POST /artifacts/namespaces/:namespace/repos |
Accepts jurisdiction |
Yes, "eu" or "us" |
No, not in the request body |
| Result if jurisdiction omitted | Unrestricted namespace | Unrestricted namespace |
| Correctable later | No, immutable after creation | No, immutable after creation |
| Available in Wrangler | No namespaces create command exists |
Yes, wrangler artifacts repos create |
That last row is the one that turns a documentation gap into an operational one.
Wrangler cannot set a jurisdiction, but it can create the namespace
The Artifacts Wrangler commands page lists seven commands: artifacts namespaces list, artifacts namespaces get, artifacts repos create, artifacts repos list, artifacts repos get, artifacts repos delete, and artifacts repos issue-token. There is no artifacts namespaces create. The page is stamped "Last updated May 18, 2026", three months before jurisdictions shipped, and the string "jurisdiction" does not appear on it once.
The practical consequence: the only tool most teams have wired into CI is the one tool that cannot express the residency requirement, while it retains the ability to create the namespace that locks the requirement out. A developer running npx wrangler artifacts repos create against a fresh namespace name has just made an irreversible residency decision from a command that never mentions residency.
Compare how R2 handles the same idea. R2's data location reference requires the jurisdiction to be declared in the Wrangler configuration file itself when a Worker binds a jurisdiction-restricted bucket:
{
"r2_buckets": [
{
"binding": "MY_BUCKET",
"bucket_name": "<YOUR_BUCKET_NAME>",
"jurisdiction": "<JURISDICTION>"
}
]
}
The jurisdiction is a first-class field in the config a reviewer reads. For Artifacts it is invisible at every point where a human might catch it. We covered the R2 side of this in detail in our note on the R2 us jurisdiction endpoint lock-in.
The hostname tells you nothing
Artifacts repos are reachable over standard Git. The Git protocol page, last updated 25 April 2026, gives the remote shape as https://<ACCOUNT_ID>.artifacts.cloudflare.net/git/<namespace>/<repo>.git, and the sample response from the create-repo route confirms it: "remote": "https://<ACCOUNT_ID>.artifacts.cloudflare.net/git/default/starter-repo.git".
One hostname. The namespace sits in the path, and the jurisdiction sits nowhere in the URL at all. An EU-restricted repo, a US-restricted repo and an unrestricted repo are indistinguishable from the remote a developer pastes into a script. If your control for data residency is "engineers will notice the wrong endpoint", it does not exist here. The only way to read the jurisdiction back is GET /artifacts/namespaces/:namespace, which nobody runs by habit.
What the docs do not say
Three absences are worth writing down, because each is a question a compliance reviewer will ask and the docs currently cannot answer.
There is no fedramp jurisdiction. R2 offers one, and its data location page, updated 19 August 2026, adds that "Cloudflare Enterprise customers may contact their account team or Cloudflare Support to get access to the FedRAMP jurisdiction." The Artifacts typed enum stops at "eu" | "us". Any workload whose storage tier is FedRAMP-scoped in R2 cannot put its build artefacts in a matching Artifacts jurisdiction today.
There is no limitations list. R2's page names services that "do not interact with R2 resources with assigned jurisdictions", starting with Logpush, and offers an S3-compatible-endpoint workaround. The Artifacts documentation set has no equivalent section. The Artifacts limits page contains no mention of jurisdiction, and neither does the Artifacts overview or the get-started guide. Whether a jurisdiction-restricted namespace can be read by a Worker in another region, or feed the build-and-deploy-on-push flow, is simply not documented.
Artifacts jurisdictions are also not part of the Data Localization Suite documentation. That landing page routes readers to Customer Metadata Boundary and Regional Services, and the word "jurisdiction" does not appear on it. Teams whose residency programme is written around the Data Localization Suite will not find this feature from the place they look first.
Pricing has not been restated for jurisdictions
The Artifacts pricing page is stamped "Last updated Apr 21, 2026" and bills on two dimensions:
| Unit | Workers Free | Workers Paid |
|---|---|---|
| Operations (1,000 operations) | Unavailable | First 10,000 per month, then $0.15 per additional 1,000 |
| Storage (GB-mo) | Unavailable | First 1 GB per month, then $0.50 per additional GB-mo |
| Jurisdiction surcharge | Not applicable | Not stated on the page |
| Replica storage | Not applicable | "Replicas do not add storage charges" |
| Free-tier availability | None | Included in Workers Paid |
Because the pricing page predates the feature by nearly four months, it neither confirms nor denies a premium for eu or us namespaces. Treat that as unknown rather than as free. The one line that does matter for residency review is the storage note: "Storage is replicated by default, and you do not need to manage repository availability or uptime." Replication and jurisdictional confinement are not in conflict on their face, since the changelog says a jurisdiction is "the only location where repo data is stored and processed", but the pricing page's replication language and the localization page's confinement language have never been reconciled in one document. Ask your account team to put the answer in writing before an audit does.
What to do this week
Enumerate first. GET /artifacts/namespaces lists what exists, and GET /artifacts/namespaces/:namespace is the only documented way to read a namespace's jurisdiction back. Anything created before 13 August 2026 predates the feature and is unrestricted by construction.
Then create the governed namespaces explicitly, over the REST API, before anyone can create them by accident. The call is small:
curl --request POST \
"https://api.cloudflare.com/client/v4/accounts/$ACCOUNT_ID/artifacts/namespaces" \
--header "Authorization: Bearer $CLOUDFLARE_API_TOKEN" \
--header "Content-Type: application/json" \
--data '{
"namespace": "my-eu-namespace",
"jurisdiction": "eu"
}'
Claim the near-miss names too. If prod-eu is the governed namespace, create prod_eu, prodeu and prod-eu-1 with the same jurisdiction, so a typo lands somewhere compliant instead of somewhere permanent. This is squatting on your own namespace, and it is cheap next to a namespace you cannot fix.
Finally, treat namespace names as a reviewed artefact. Pin the namespace string in the Wrangler configuration binding, fail CI on any namespace not on the allow-list, and stop templating namespace names from branch names or environment variables. The migration cost here is real: because jurisdiction is immutable, correcting a mistake means creating a new namespace, re-pushing every repo, re-issuing every repo token, and updating every remote. The real cost is usually the migration, not the code.
India-specific considerations
There is no Indian jurisdiction for Artifacts, and none for R2 either. Teams building under the Digital Personal Data Protection Act 2023 should note that DPDP does not impose a blanket localization requirement in the way GDPR-driven programmes often assume, but sectoral rules and customer contracts frequently do. If a contract commits you to EU-only processing for a European customer's build artefacts, eu is available today; if it commits you to India-only processing, Artifacts cannot meet it, and the artefact store has to sit elsewhere. Our DPDP engineering playbook for Indian startups covers how to decide which data classes actually need a residency boundary before you spend a quarter building one.
FAQ
How eCorpIT can help
Our data residency and DPDP cloud architecture practice exists for exactly this problem: a residency boundary that has to survive an audit, not just a design review. The work is usually inventory first, then the irreversible settings, then the CI guardrails that stop an engineer creating a permanent exception by accident. eCorpIT is ISO 27001:2022 certified and CMMI Level 5 appraised, and we design applications aligned with GDPR and DPDP requirements. If Artifacts, R2 or a similar store sits inside your compliance perimeter, book a data residency architecture review and we will map which of your settings are still changeable.
References
Last updated 23 August 2026.
