Cloudflare Workflows can now be pinned to a jurisdiction

Cloudflare added jurisdiction restrictions to Workflows on 27 October. Setting jurisdiction on a Workflow’s binding keeps its instances running, and its data stored, inside that boundary rather than wherever the network has spare capacity. Three jurisdictions are supported: eu, us and fedramp (FedRAMP-Moderate data centres).

{
  "workflows": [
    {
      "name": "my-workflow",
      "binding": "MY_WORKFLOW",
      "class_name": "MyWorkflow",
      "jurisdiction": "eu"
    }
  ]
}

The restriction is set once, at creation, and cannot be changed. If a deployed Workflow’s jurisdiction no longer matches what’s in your config, wrangler deploy and wrangler versions upload refuse to run. Moving to a different jurisdiction means renaming the Workflow or deleting the old one, which also deletes its instances. It needs Wrangler 4.152.0 or later.

Why it matters: Cloudflare already offers this jurisdiction model for KV, D1 and Queues; this closes the gap for durable, multi-step jobs that need to stay inside the EU for GDPR or inside a FedRAMP-Moderate boundary for US government work.

The caveat: a Workflow’s settings, as opposed to its instance data, are stored outside the specified jurisdiction, so this doesn’t make the whole deployment invisible to Cloudflare.