Cloudflare has introduced a jurisdiction attribute for Workflows, both in the Wrangler configuration and in the exported Workflow class. Setting this attribute forces every workflow instance to run and keep its data inside the chosen jurisdiction, providing a direct compliance path for data‑localization regulations.
Declaring a Jurisdiction
Include the jurisdiction key in the workflows array of wrangler.jsonc or in wrangler.toml. The value must be one of the supported identifiers.
{
"workflows": [
{
"name": "my-workflow",
"binding": "MY_WORKFLOW",
"class_name": "MyWorkflow",
"jurisdiction": "eu"
}
]
}
[[workflows]]
name = "my-workflow"
binding = "MY_WORKFLOW"
class_name = "MyWorkflow"
jurisdiction = "eu"
Supported Jurisdictions
The platform currently recognises three identifiers:
- eu – European Union data centres.
- us – United States data centres.
- fedramp – FedRAMP‑Moderate compliant data centres.
Operational Considerations
- A workflow’s jurisdiction is fixed at creation time; it cannot be altered later.
- If an existing workflow’s jurisdiction differs from the one declared in the source,
wrangler deployandwrangler versions uploadwill abort before uploading the Worker. - Deployments that use this feature require Wrangler version 4.152.0 or newer.
- Because the restriction is enforced by the platform, no additional networking or storage controls are needed to keep data within the selected region.
Related CloudNinjas coverage: hands-on guides.
What This Means For Practitioners
When building or operating Cloudflare Workflows, evaluate the following steps:
- Identify the regulatory regime that applies to your workload (GDPR, FedRAMP, etc.).
- Choose the appropriate jurisdiction identifier and add it to your workflow definition before the first deployment.
- Verify that your Wrangler toolchain meets the minimum version requirement.
- Plan for the immutability of the jurisdiction setting: any change will require creating a new workflow rather than modifying an existing one.
