Cloudflare Workflows can now cap concurrency per workflow
A new concurrency.limit setting caps how many instances of a single Workflow run at once, so one busy Workflow cannot drown a downstream database or API.
Cloudflare announced on 10 November that Workflows can now set a concurrency limit on a single Workflow, rather than only on the account as a whole. Instances above the limit are not rejected: they queue and start automatically as running instances finish.
The limit is set in wrangler.json or wrangler.toml and needs Wrangler 4.127.0 or above. It must be a positive integer and cannot exceed your account’s overall concurrency limit, which is 100 instances on Workers Free and 50,000 on Workers Paid. Leave it out of a deployment and the cap is removed, so it has to be reapplied every time you deploy.
{
"workflows": [
{
"name": "my-workflow",
"binding": "MY_WORKFLOW",
"class_name": "MyWorkflow",
"concurrency": { "limit": 10 }
}
]
}Why it matters: if a Workflow calls a database or third-party API that falls over past a certain number of concurrent connections, this is the first way to throttle just that Workflow instead of your whole account’s Workflows budget. It also stops one high-volume Workflow from starving every other Workflow of your shared concurrency pool.
The caveat: because the limit resets on any deploy that omits it, a routine redeploy without the config present will silently remove your throttle.