Skip to content

SYSTEM Cited by 3 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:

Saga rollbacks (2026-06-25)

Workflows natively supports the saga pattern via per-step rollback handlers declared as metadata on step.do():

await step.do("debit-bank-a", () => bankA.debit(from, amount), {
  rollback: async ({ output }) => bankA.credit(from, amount, output.id),
  rollbackConfig: {
    retries: { limit: 10, delay: '30 seconds', backoff: 'exponential' },
    timeout: '2 minutes',
  },
});

When the Workflow fails terminally, the engine invokes registered rollback handlers in reverse step-start order (not completion order — important for parallel steps). Each rollback handler receives the original error, step context, and persisted output (which may be undefined if the step failed before persisting).

Under the hood, the engine records rollback registration in the durable step history and keeps each handler as a Workers RPC stub (callable reference). On engine restart, the standard replay mechanism re-runs the Workflow code, skipping completed step bodies but re-registering rollback stubs (patterns/compensation-stub-recovery-via-replay).

Rollback handlers run through the normal step machinery (retries, timeouts, lifecycle events). If a handler exhausts retries, the Workflow enters the Errored state; remaining handlers are skipped. Canonicalises patterns/saga-rollback-as-step-metadata.

(Source: sources/2026-06-25-cloudflare-saga-rollbacks-for-workflows.)

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 · 608 distilled / 1,858 read