Declare Cloudflare Workflows via Wrangler exports for clearer configuration

Cloudflare Workers can now list their Workflows directly in the exports section of the Wrangler configuration file, rather than relying solely on a workflows binding. This shift lets engineers define schedule, limits, and retention for a Workflow even when the Worker never invokes it, simplifying configuration and reducing the need for placeholder bindings.

What Changed in the Configuration Model

The exports object now accepts entries keyed by the class name that extends WorkflowEntrypoint. Each entry must specify type="workflow" and can include the same options previously available on a binding: name, schedules, limits, and default_retention. Wrangler 4.139.0+ reads these entries and creates or updates the corresponding Workflow during wrangler deploy.

{
  "exports": {
    "MyWorkflow": {
      "type": "workflow",
      "name": "my-workflow",
      "limits": { "steps": 25000 },
      "schedules": ["0 * * * *"]
    }
  }
}

The same configuration can be expressed in wrangler.toml using the [exports.MyWorkflow] table syntax.

Operational Impact

When a deployment runs, Wrangler treats each exports workflow entry as a declarative resource. The platform ensures the Workflow exists with the supplied settings, eliminating the need to maintain a separate binding solely for registration purposes. Engineers can still declare a Workflow as both a binding and an export, but the class must match and any overlapping settings must be identical; conflicting values are rejected.

Workflow names remain globally unique within an account. A workflows binding that points to a Workflow in another Worker cannot reuse a name that appears as an export in the current Worker. This constraint requires careful naming discipline across the codebase.

Architectural and Security Considerations

Using exports makes the Workflow definition part of the Worker’s static artifact, which can improve traceability in version control and CI pipelines. Because the definition lives in the same configuration file as other exports, any accidental exposure of the file (e.g., committing to a public repo) also reveals the Workflow’s schedule and limits. Teams should treat the configuration file with the same confidentiality as other deployment manifests.

Since the same class can be referenced both as a binding and an export, developers must ensure the class implements WorkflowEntrypoint correctly and that any runtime code does not unintentionally depend on the presence of a binding when only an export is declared.

Related CloudNinjas coverage: hands-on guides.

What This Means For Practitioners

• Upgrade Wrangler to 4.139.0 or later before using exports for Workflows.
• Move static Workflow definitions out of workflows bindings and into exports to reduce configuration noise.
• Validate that Workflow names are unique across the account to avoid deployment errors.
• When a Workflow is needed only for scheduling or limits, declare it as an export without adding a binding.
• Review repository access controls for wrangler configuration files to protect schedule and limit metadata.