Skip to content

SYSTEM Cited by 2 sources

Cloudflare Workflows

Workflows is Cloudflare's durable-execution primitive for long-running, retriable, step-checkpointed workflows built on Workers (developers.cloudflare.com/workflows). Think: background jobs that span hours or days, steps retry independently, state persists across step boundaries.

Role

  • Long-running orchestration without keeping a Worker hot.
  • Per-step retry / checkpoint semantics.
  • Complements Durable Objects for coordination and state.

Programming model

A Workflow is a class extending WorkflowEntrypoint with an async run(event, step) method. Every side-effecting action is wrapped in step.do('name', async () => {...}) so each step survives failures independently, resumes exactly where it left off, and is checkpointed durably before advancing.

import { WorkflowEntrypoint } from 'cloudflare:workers';

export class MyWorkflow extends WorkflowEntrypoint {
  async run(event, step) {
    const a = await step.do('first', async () => doA());
    await step.sleep('24 hours');
    await step.waitForEvent('approval', { timeout: '24 hours' });
    return step.do('second', async () => doB(a));
  }
}
  • step.do() — retryable checkpointed step.
  • step.sleep() — hibernates; no VM held open during the wait.
  • step.waitForEvent() — indefinite wait for an external event (approval, webhook, timer).
  • .create() / .status() / .pause() — instance-level APIs on the Workflow binding.

Registered in wrangler.jsonc:

"workflows": [
  { "name": "my-workflow", "binding": "WORKFLOW", "class_name": "MyWorkflow" }
]

One binding → one class_name → one deploy. Statically bound. Canonicalised in patterns/workflow-primitives-as-annotated-classes.

Workflows V2 capacity (2026-05-01 disclosure)

Workflows V2 is "redesigned for the agentic era" — per-account limits as disclosed in the 2026-05-01 Dynamic Workflows launch:

  • Up to 50,000 concurrent workflow instances per account.
  • Up to 300 new instances per second per account.

These are ambient capacity context for platforms running per- tenant workflows at fleet scale. First wiki disclosure of the V2 capacity envelope. (Source: Dynamic Workflows.)

Dynamic dispatch via Dynamic Workflows (2026-05-01)

The static one-class-per-deploy binding was the last missing piece for multi-tenant platforms — app platforms where the AI writes TypeScript per tenant, CI/CD products where each repo has its own pipeline, agents SDKs where each agent writes its own durable plan. @cloudflare/dynamic-workflows (2026-05-01) lifts the constraint: a single Worker Loader routes every create() call and every subsequent run(event, step) invocation into the right tenant's code, loaded as a Dynamic Worker at runtime. The Workflows engine's durability machinery (IDs, step.sleep(), step.waitForEvent(), retries, hibernation) continues to work unchanged — "everything else falls through to the real Workflows engine untouched."

Canonicalised in:

Local / remote parity

Workflows are among the binding types introspectable via Local Explorer's local mirror API at /cdn-cgi/explorer/api, backed by Miniflare (Source: sources/2026-04-13-cloudflare-building-a-cli-for-all-of-cloudflare).

Seen in

Last updated · 542 distilled / 1,571 read