Skip to content

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

  • systems/cloudflare-dynamic-workflows — the library.
  • per-tenant-dynamic-code-dispatch — the general three-layer dispatch shape (engine / Worker Loader / tenant code).
  • metadata-envelope-in-durable-payload — the wire-format trick that threads tenant ID through the persisted payload so the engine can replay into the right tenant's code.
  • dynamic-binding-over-static-binding — the general platform-design shape of which Dynamic Workflows is the durable-execution instance.

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 (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 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

  • sources/2026-07-30-cloudflare-dogfooding-at-scale-migrating-cdnjs-to-cloudflares-developer-platform — cdnjs ingestion pipeline runs entirely on Workflows: cron-triggered PackageUpdatesWorkflow every 10 min → per-version DownloadPackageWorkflow → per-file ProcessingWorkflow → PublishingWorkflow. Hit the 1,024-step limit during migration; raised to 10K/25K for all customers. Canonical instance of durable-execution-for-ingestion at 9B req/day scale.
  • sources/2026-04-13-cloudflare-building-a-cli-for-all-of-cloudflare — Workflows is one of the introspectable binding types in Local Explorer.
  • sources/2026-05-01-cloudflare-introducing-dynamic-workflows-durable-execution-that-follows-the-tenant — Workflows V2 capacity envelope disclosed; Dynamic Workflows bridges Workflows with Dynamic Workers for multi-tenant dispatch; engine is left unchanged and additive wrapper glue handles routing.
  • sources/2026-05-28-cloudflare-how-we-built-cloudflares-data-platform-and-an-ai-agent-on-top-of-it — Workflows is the execution substrate for Transformer, Town Lake's ELT engine. Pipelines are YAML-frontmatter-defined SQL DAGs; Transformer compiles the DAG and runs it on Workflows, with per-DAG state managed by Durable Objects, definitions stored in R2, and run history in D1. Canonicalises elt-on-workflows-with-do-state — sibling to the existing CI pipeline shape: same architectural pattern (customer-authored YAML, Workflow execution, DO state) applied to a different domain (data engineering, not CI).
  • sources/2026-06-25-cloudflare-saga-rollbacks-for-workflows — Saga rollbacks shipped as a native step.do() option. Per-step { rollback, rollbackConfig } declares compensation logic co-located with the forward action. Engine executes rollbacks in reverse step-start order on terminal failure. Internally: durable step history records rollback registration; Workers RPC stubs hold callable handler references; replay rebuilds stubs after restart. Canonicalises saga-rollback-as-step-metadata and compensation-stub-recovery-via-replay.
  • sources/2026-09-11-cloudflare-introducing-automatic-remediation-policies-with-casb — Workflows as the durable remediation pipeline behind CASB automatic remediation policies. After a Queue-fed Worker matches a finding to a policy, it hands the job to a Workflow "for durable, fault-tolerant execution" — jobs survive process restarts and retry automatically. Notably, third-party SaaS API rate limits are absorbed as backoff-and-retry inside the Workflow ("pauses for the appropriate backoff window and retries without dropping the job") rather than dropped jobs — the action side of patterns/closed-loop-remediation, target ≤ 5 min detection-to-remediation.
  • sources/2026-09-30-cloudflare-detect-and-send-production-issues-straight-to-your-agent — Workflows as the dogfood target for Workers Issues error monitoring. Because Workflows is built entirely on the Workers platform, Cloudflare turned on Issues for it and, within a day, surfaced two edge-case bugs hidden in a large traffic volume: (1) a control-plane migration stuck in a retry loop on a SQLite foreign-key error while applying migrations, and (2) a deletion process that never completed — deleting Workflow instances could exceed a Workers subrequest limit and leave the deletion unfinished. Both issues were auto-routed to Cloudflare OS, which followed the errors into the Workflows code and proposed a fix for each. First wiki instance of Workflows as an observed production system rather than an execution substrate — the retry-loop and subrequest-limit edge cases are concrete Workflows-internals data points (state/step/retry bookkeeping and the per-invocation subrequest ceiling).

Agent Development Lifecycle role (2026-08-04)

Cloudflare positions Workflows as the control plane for an agent-operated delivery lifecycle, not merely as a CI executor. A workflow can retain stage context, dispatch agents, child workflows, containers, and browsers, enable a feature-flagged test cohort, inspect logs and traces, and wait for production signals before advancing or reversing a release. This is the canonical workflow substrate for ADLC and workflow-orchestrated agent lifecycles. The article provides an illustrative CI runner graph, but does not provide measured end-to-end reliability or production-factory scale. (Source: sources/2026-08-04-cloudflare-agent-development-lifecycle)

Last updated · 766 distilled / 2,225 read