Cloudflare Workflows
If your stack is on Cloudflare Workers, Cloudflare Workflows is the native durable-execution option — no extra infra, billed alongside Workers, and able to call other Workers/D1/R2/Queues directly. Useful comparison point for WDK: same model, different runtime constraints. Worth knowing both to pick the right tool and to recognize the durable-execution pattern as it spreads across edge platforms.
What It Defines
Durable-execution runtime built on Cloudflare Workers and Durable Objects. A workflow is a TypeScript class extending `WorkflowEntrypoint`; its `run(event, step)` method is replayed deterministically across `step.do(name, fn)` and `step.sleep(name, duration)` checkpoints, with state persisted by Cloudflare on the global edge. Triggered via bindings, HTTP, or `WorkflowsBinding.create()`. Same event-sourced replay model as WDK and Temporal, but tightly integrated with the Workers runtime — steps must obey Workers' I/O constraints, and the workflow runs wherever its Durable Object lives.
Canonical (Normative)
Convenient (Practical)
Edge platform that publishes Cloudflare Workflows — a durable-execution runtime built on Workers and Durable Objects. Workflows are TypeScript classes whose `run()` method is replayed deterministically across `step.do()` and `step.sleep()` checkpoints, with state persisted on Cloudflare's global network. Cloudflare also publishes Workers, Durable Objects, R2, KV, Queues, and the Pingora-based proxy stack.
Related Specs
WDK is the durable-execution model arriving inside the JavaScript ecosystem proper: instead of writing a state machine, you write `async` code with two extra string directives and you get crash-safe, resumable, retry-aware, observable workflows. If you're building AI agents, multi-step background jobs, human-in-the-loop flows, or anything that previously needed BullMQ + a state machine + careful idempotency, WDK collapses that into a single mental model. Even if you don't pick WDK specifically, the directives + replay model are the durable-execution pattern Temporal pioneered and Cloudflare/Restate/DBOS now ship — knowing one teaches you the rest.
Temporal is the prior art every durable-execution framework is measured against. If you're picking a workflow runtime, evaluating WDK, or reading a paper on durable execution, the Temporal model — workflows + activities + signals + timers + event history — is the vocabulary. Even if you choose WDK or Step Functions for a specific stack, understanding Temporal makes their tradeoffs legible (sandbox restrictions vs full Node, hosted runtime vs self-host, JSON DSL vs code).
Step Functions is the most widely deployed durable-execution runtime, and ASL is the JSON contract under it. If you ever need a state machine to coordinate Lambdas, run a Saga, or fan out parallel work in AWS, you'll write ASL — and unlike WDK or Temporal it's a declarative DSL, not code, which is both its strength (visualizable, statically inspectable) and its weakness (loops and dynamic control flow are awkward). Worth knowing as the canonical "workflow as JSON" comparison point.
If you remember one thing about durable execution, remember this: workflow code runs many times and the event log decides what's real. That single fact explains every WDK rule — why steps must be idempotent, why you can't read `Date.now()` directly in a workflow, why parameters are passed by value, why mutating an object inside a step doesn't propagate, and why bundlers occasionally bite you. Internalize the replay model and the rest of WDK (and Temporal, and Cloudflare Workflows) becomes obvious.