Set Cloudflare Artifacts EU data residency in API
The namespace creation call takes the jurisdiction in the request body. For an EU-bound namespace, the API payload needs the jurisdiction field set to eu when you create the namespace. Cloudflare Artifacts supports the European Union and the United States as the only jurisdiction choices for repository data.
That matters because the boundary sits at namespace level, not repository level. A repository does not get to wander off somewhere else because someone clicked the wrong option in a later edit. The namespace decides where the data lives and where it is processed.
http
POST https://api.cloudflare.com/client/v4/accounts/$ACCOUNT_ID/artifacts/namespaces
Authorization: Bearer $CLOUDFLAREAPITOKEN
Content-Type: application/json
json
{
“namespace”: “my-eu-namespace”,
“jurisdiction”: “eu”
}
Set the jurisdiction at namespace creation
The jurisdiction belongs in the initial namespace request. That keeps the residency choice tied to the container that all repositories inherit from. If you are modelling a system with EU residency requirements, the namespace is the control point, not each individual repository.
Send the jurisdiction field in the namespaces request
The API accepts a jurisdiction field alongside the namespace name. Set it while creating the namespace, not after. Omitting it creates an unrestricted namespace, which is a neat way to lose the boundary you thought you had.
A practical setup looks simple enough:
namespace: a name for the repository groupjurisdiction:euorus
That is the whole decision. There is no later flip to tidy it up.
Keep repository storage inside the selected region
Every repository created in that namespace follows the same jurisdiction. That gives you one place to control repository storage and processing for the whole set. If the namespace is EU-bound, the repositories in it stay EU-bound. If it is US-bound, the same applies there.
This is tidy from a compliance angle, but it also means you need to separate workloads cleanly. A shared namespace is a shared jurisdiction. If you mix data with different residency needs, the namespace choice becomes a constraint you will feel very quickly.
Handle the bits that do not change later
The awkward part is the lack of editability. Namespace jurisdiction is immutable after creation, so the decision is permanent for that namespace. If the wrong jurisdiction lands in production, the fix is not a field update. It is a new namespace and a migration.
Treat namespace jurisdiction as immutable
Immutable settings are convenient right up until someone asks for a change. Then they are just accurate. For Cloudflare Artifacts, the jurisdiction is fixed once the namespace exists. That is useful for enforcement, but it also means the API call has to be right the first time.
The safest pattern is to decide the residency boundary before creating anything that matters. If the namespace is wrong, every repository created under it is wrong with it.
Decide what to do with unrestricted namespaces
If you omit the jurisdiction, Artifacts creates an unrestricted namespace. That may be fine for non-sensitive data or throwaway setups, but it is a poor default for anything that has residency requirements attached.
So the operational choice is blunt:
- set
eufor EU residency - set
usfor US residency - leave it out only if unrestricted storage and processing are acceptable
Once the namespace exists, there is no rescue button for the jurisdiction field.
