Invoke Cloudflare Workflows Directly from Workers Using ctx.exports

Cloudflare Workers can now invoke the Workflows they declare directly through ctx.exports, removing the need for a separate workflows binding. This change simplifies the code path, aligns the API surface with other bindings, and preserves existing workflow instances when you migrate from a binding to an export.

What Changed

Previously a Worker needed a workflows binding in its wrangler.toml to call a Workflow defined elsewhere. The new model lets a Worker expose a Workflow via the exports field of its Wrangler configuration and call it with ctx.exports.WorkflowClass.create(...). The Workflow is identified by its class name and retains the same method signatures as a binding.

export default {
  async fetch(request, env, ctx) {
    const instance = await ctx.exports.MyWorkflow.create({
      params: { name: "World" },
    });
    return Response.json({ id: instance.id });
  },
};

If a binding and an export share the same name, they reference the same set of instances, so moving a Workflow from a binding to an export does not disrupt in‑flight executions.

Architectural and Operational Implications

• Simplified deployment configuration: Removing the workflows binding reduces the number of entries in wrangler.toml, lowering the risk of mismatched names or stale bindings.
• Consistent runtime API: All bindings—including KV, Durable Objects, and now Workflows—are accessed through the same ctx namespace, making codebases easier to read and refactor.
• Local development parity: The wrangler dev command, Cloudflare Vite plugin, and Workers Vitest integration already support executing Workflows via ctx.exports. Developers must use Wrangler 4.142.0 or newer, and the matching versions of @cloudflare/vite-plugin (≥ 1.61.0) or @cloudflare/vitest to get this behavior locally.
• Instance continuity: Because a binding and an export with the same name share instances, you can migrate to the new pattern without restarting or losing stateful workflow runs.

Security and Instance Management Considerations

The underlying security model of Workflows does not change; the same permissions that applied to a binding now apply to the export. However, practitioners should verify that any environment variables or secrets referenced by the Workflow remain accessible when the Workflow is invoked via ctx.exports. Since the API surface is identical, existing IAM or token scopes continue to govern access, but the reduced configuration surface may lower the chance of accidental exposure through mis‑named bindings.

Related CloudNinjas coverage: hands-on guides.

What This Means For Practitioners

Adopt the exports pattern for new Workers that need Workflows, and consider migrating existing Workers to eliminate the explicit workflows binding. Update your wrangler.toml to list the Workflow class under exports, ensure your local toolchain meets the version requirements, and run your test suite to confirm that instance continuity is preserved. Monitoring should continue to focus on workflow execution metrics; the change does not introduce new observable endpoints, but it does simplify the configuration footprint you need to audit.