Cloudflare shipped @cloudflare/dynamic-workflows, a roughly 300-line MIT-licensed library that closes a long-standing gap in its developer platform: durable workflows whose code is different for every tenant, every agent, every request. It's the third leg of a stool the company has been building for months—Dynamic Workers solved compute, Durable Object Facets solved storage, Artifacts solved source control, and now Dynamic Workflows solves durable execution.
The Problem Workflows Couldn't Solve
Cloudflare Workflows is the company's durable execution engine—a run(event, step) function where every step survives failures, can sleep for hours or days, and resumes exactly where it left off. Workflows V2 brought it to 50,000 concurrent instances and 300 new instances per second per account. But it shipped with one assumption: workflow code is part of your deployment. One wrangler.jsonc binding, one class, per deploy.
That stops working the moment a customer wants to ship their own workflow. The cases are now everywhere: app platforms where the AI writes TypeScript for every tenant, CI/CD products where each repo defines its own pipeline, agents SDKs where each agent writes its own durable plan. There is no single class to bind.
How Dynamic Workflows Works
The library lets a single Worker—the Worker Loader—route every create() call to a different tenant's code, and have the Workflows engine dispatch run(event, step) back to that same code seconds, hours, or days later. The tenant calls env.WORKFLOWS.create(...) against what looks like a perfectly normal Workflow binding. Workflow IDs, .status(), .pause(), retries, hibernation, step.sleep('24 hours'), step.waitForEvent()—all work unchanged.
Under the hood, the wrapped binding rewrites the payload to embed tenant metadata in the envelope, then forwards to the real Workflows engine. When the engine wakes the workflow up later, it calls back into a class registered in wrangler.jsonc, which unwraps the envelope and hands the metadata to a loadRunner callback the platform writes. That callback fetches the tenant's source from R2, picks a region based on plan tier, attaches a per-tenant tail Worker, or whatever else—then hands back to the Worker Loader, which boots a Dynamic Worker in single-digit milliseconds.
The Real Story Is Dynamic Workers
Cloudflare is candid about what's actually doing the work. Every interesting line of the library is glue around .create() on one side and WorkflowEntrypoint on the other. The actual sandboxing, RPC routing, isolate caching, and hibernation between steps is all Dynamic Workers underneath. Durable Object Facets is the same pattern applied to Durable Objects. Dynamic Workflows is that pattern applied to durable execution.
And Cloudflare isn't stopping there. The company says every binding Workers exposes is heading for a dynamic counterpart: queues where each producer ships its own handler, caches, databases, object stores, AI bindings, and MCP servers where every tenant brings their own tools. "Whatever you bind to a Worker today, you will soon be able to bind dynamically: dispatched per tenant, per agent, per request, at zero idle cost."
CI/CD Is the Headline Use Case
The example Cloudflare leans on hardest is CI/CD, and it's a clean fit. Every CI platform is, underneath, a dispatcher of per-repo configuration files: run these steps in this order, with these secrets, cache these directories, upload these artifacts. Each PR spawns an instance that has to run to completion, survive a machine crash, retry a flaky step, stream logs, and pause for approvals. That's the exact shape of a durable workflow.
The reason CI hasn't been built this way is that nobody had a primitive where the workflow itself is different per repo, dispatched at runtime, at zero provisioning cost. A traditional CI run looks like: allocate VM (15-30s) → pull image (10s) → git clone (10s) → npm ci (30-60s) → tests. Several minutes of ceremony before anything happens. On the Dynamic Workers stack, it's edge-fork the repo with Artifacts (seconds), boot a fresh isolate per step in milliseconds, hibernate while waiting on approvals. Nothing has to cold-start. Nothing has to be kept warm. The repo doesn't move—the compute comes to it.
Why It Matters for Web Developers
For platform builders, Dynamic Workflows changes the unit economics of multi-tenant SaaS. Idle tenants cost approximately nothing, active tenants share hardware through isolate-level multi-tenancy, and the floor drops several orders of magnitude. Cloudflare's framing: a platform that used to cap at thousands of paying customers can now reasonably serve tens of millions.
For agent platforms, this is the piece that lets an LLM-written plan be a first-class Cloudflare Workflow—where every step.do() is independently retryable, every step.sleep('24 hours') hibernates for free, and every step.waitForEvent() waits indefinitely for human approval. The agent writes the workflow, the platform runs it, and neither has to know ahead of time what the plan looks like. npm install @cloudflare/dynamic-workflows works today; it runs on Dynamic Workers, currently in open beta on the Workers Paid plan.