Declare Workflows in the exports configuration
Workers can now declare Workflows directly in the exports field of the Wrangler configuration file, eliminating the need for a workflows binding when the Worker doesn't call the Workflow itself. This enables cleaner configuration and automatic Workflow creation or updates during deployment.
You can now declare the Workflows a Worker defines in the exports field of your Wrangler configuration file. Previously, a Worker could only define a Workflow through a workflows binding, even when the Worker never called the Workflow itself.
Key each entry by the name of the class that extends WorkflowEntrypoint:
{
"exports": {
"MyWorkflow": {
"type": "workflow",
"name": "my-workflow",
"limits": {
"steps": 25000,
},
"schedules": ["0 * * * *"],
},
},
}[exports.MyWorkflow]
type = "workflow"
name = "my-workflow"
schedules = [ "0 * * * *" ]
[exports.MyWorkflow.limits]
steps = 25_000
A workflow export accepts the same settings as a workflows binding: limits, schedules, and default_retention. When you run wrangler deploy, Wrangler creates or updates the Workflow with these settings.
You can declare a Workflow as both a binding and an export. Both declarations must use the same class, and cannot set the same setting to different values.
A workflows binding to a Workflow in another Worker cannot use the same name as a Workflow export in this Worker. Workflow names are unique per account.
Workflow exports require Wrangler 4.139.0 or above.
For more information, refer to Declare Workflows in exports.
Source: original entry ↗
More from Cloudflare
Follow Cloudflare to get its new changes in your feed and email digest.
Improved HTTP/3 client cancellation reporting
Cloudflare now properly stops HTTP/3 requests when clients cancel them and reports these consistently as 499 status codes. This reduces unnecessary origin work and provides clearer visibility into client behavior across all plan types.
WAF failed detections field now available in Rules
A new cf.appsec.request.failed_detections field lets you control how rules handle requests when security detections fail. This array of detection IDs covers content scanning, WAF attack scoring, attack signatures, leaked credentials, and AI-based PII/prompt injection/custom topic detection failures, and works across custom rules, rate limiting rules, and request header transform rules.
Markdown for Agents: More efficient in-process streaming conversion
Markdown for Agents now uses an in-process streaming engine at the edge to convert HTML, reducing overhead and memory use. The conversion limit increased from 2 MiB to 6 MiB, and token count headers are no longer generated.