Cloudflare Dynamic Workflows Extend Durable Execution to Per‑Tenant and Per‑Agent Code

By Steef‑Jan Wiggers – Cloud Queue Lead Editor

---

What changed?

Cloudflare announced Dynamic Workflows, an MIT‑licensed TypeScript library that removes the long‑standing restriction that a workflow definition must be baked into a single deployment.

• Runtime code loading – A platform can now route each WORKFLOWS.create() call to a tenant‑specific module that is fetched on demand.
• Preserved durability – All existing guarantees—step retries, hibernation, step.sleep(), step.waitForEvent()—continue to work unchanged.
• Lightweight orchestration – The new Worker Loader sits between the durable engine and the tenant code, attaching tenant metadata to every persisted payload and re‑hydrating the correct module when the engine wakes.
• Open source – The library (≈300 LOC) is published on npm as @cloudflare/dynamic‑workflows and includes a browser‑based playground.

The change is most visible in three classic multi‑tenant scenarios:

1. AI‑generated per‑tenant code – An AI service writes a custom TypeScript workflow for each customer.
2. CI/CD pipelines as code – Every repository defines its own pipeline logic that the platform loads on the fly.
3. Agentic AI plans – Each autonomous agent supplies a durable plan that can pause for human approval or external events.

All of these use‑cases now share a single deployment surface while still enjoying the edge‑distributed, zero‑idle‑cost model that Cloudflare Workers provide.

---

Provider comparison

Feature	Cloudflare Dynamic Workflows	Temporal	Inngest	AWS Step Functions
Dynamic code loading per tenant	Yes – loader fetches tenant module at runtime, V8 isolate isolation	No – workflow definitions are compiled into a service binary; code changes require redeploy	No – functions are static; dynamic routing must be built on top of the platform	No – state machines are defined in JSON/YAML; task definitions are static
Durable execution guarantees	Same as native Workflows (retries, hibernation, event waiting)	Full durability via History Service and Replicated DB	Guarantees retries and event handling, but no built‑in hibernation	Supports retries and error handling, but no native sleep‑until‑event semantics
Edge distribution	Runs on Cloudflare edge network, sub‑second cold start	Runs in dedicated clusters (often in a single region)	Runs in the provider’s cloud (usually region‑bound)	Region‑bound, no edge execution
Isolation model	V8 isolates per request, zero‑idle cost for idle tenants	Process isolation per worker, requires provisioned capacity	Container‑level isolation, costs accrue per active worker	Lambda‑based tasks, cost per execution
Pricing model	Pay‑as‑you‑go for Workers, Durable Objects, and storage; idle tenants incur negligible cost	Pay per workflow execution + storage; requires dedicated capacity for high throughput	Pay per event + compute; no special idle‑cost model	Pay per state transition + Lambda execution; idle state machines are free but each transition costs
Open‑source SDK	@cloudflare/dynamic‑workflows (MIT)	Temporal SDKs (Apache 2)	Inngest SDK (MIT)	No SDK for custom code, uses CloudFormation/Step Functions definitions
Typical use‑case focus	Multi‑tenant SaaS, AI agents, CI/CD on the edge	Large‑scale microservice orchestration, internal business processes	Event‑driven serverless workflows, webhook pipelines	Enterprise workflow orchestration, batch jobs

Pricing considerations

• Cloudflare – Workers are billed per million requests (≈$0.50 M) and per GB‑second of compute. Durable Objects add a small per‑million‑writes charge. Because idle tenants do not keep any compute alive, the marginal cost of adding a new tenant is essentially the storage of its code and metadata.
• Temporal – Requires a managed service (Temporal Cloud) or self‑hosted cluster. Pricing is based on workflow executions and storage, with a minimum provisioned capacity that can become significant for a platform with many low‑traffic tenants.
• Inngest – Charges per event and per GB of retained state. There is no separate idle charge, but every event (including heartbeats) adds up, which can be noticeable for long‑running, low‑frequency workflows.
• AWS Step Functions – $0.025 per 1 000 state transitions plus Lambda execution costs. A platform that creates a new state machine per tenant would quickly hit a high fixed‑cost floor.

Overall, Cloudflare’s model offers the lowest barrier for massive tenant counts because the cost curve stays flat until the tenant actually triggers workflow steps.

---

Business impact

1. Cost compression for multi‑tenant platforms

By moving the compute to the edge and eliminating per‑tenant VM provisioning, Cloudflare claims the idle cost per tenant drops to “approximately nothing”. A SaaS that previously capped at a few thousand paying customers because of VM‑based CI/CD or orchestration can now target tens of millions with only incremental storage and request costs.

2. Faster time‑to‑value for AI‑driven services

AI agents that generate their own execution plans no longer need a pre‑built SDK or a separate deployment pipeline. The platform simply stores the generated TypeScript, the Dynamic Worker fetches it, and the durable engine guarantees retries and sleeps. This reduces the feedback loop for feature rollout from days (building images, rolling out VMs) to seconds.

3. Simplified architecture stack

The announcement ties together four Cloudflare primitives:

• Artifacts – Git‑style versioned storage for code and assets.
• Dynamic Workers – Lightweight isolates that boot in milliseconds.
• Dynamic Workflows – Durable orchestration that can pause for free.
• Sandboxes – Full OS environments for heavy steps, started from snapshots.

Instead of stitching together separate CI runners, storage buckets, and queue services, a platform can rely on a single, coherent stack that is already edge‑distributed.

4. Competitive differentiation

While Temporal, Inngest, and AWS Step Functions excel at durable orchestration, none provide per‑tenant code loading at the edge with zero idle cost. For companies building AI agent platforms, marketplace‑style SaaS, or per‑repo CI pipelines, Cloudflare’s approach creates a clear advantage in both performance (sub‑second isolate start) and economics (no idle VM charge).

5. Migration considerations

Moving an existing CI/CD or agent platform to Dynamic Workflows involves:

1. Exporting workflow definitions to TypeScript modules that can be fetched on demand.
2. Replacing static bindings with the wrapWorkflowBinding({ tenantId }) helper.
3. Storing code in Cloudflare Artifacts or another edge‑accessible bucket.
4. Testing isolation – each tenant runs in its own V8 isolate; verify that any shared native dependencies are either bundled or moved to a sandbox.
5. Cost modeling – simulate workload patterns to compare current VM/EC2 spend against Workers request volume and Durable Object writes.

The migration path is relatively straightforward because the library mirrors the existing Workflows API; existing retry, sleep, and event‑wait semantics remain unchanged.

---

Outlook

Cloudflare hints that every binding—queues, caches, databases, AI models—will eventually get a dynamic counterpart. If the roadmap materializes, a platform could achieve true zero‑idle‑cost multi‑tenant operation: compute, storage, and even AI inference would spin up only when a tenant issues a request.

For enterprises evaluating a move away from traditional VM‑based orchestration, the combination of edge isolation, dynamic code loading, and durable execution makes Cloudflare a compelling option, especially when the target audience includes millions of low‑traffic tenants or AI agents that need to write their own plans.

---

*For a hands‑on look, see the npm package and the GitHub repository, which include a browser playground and a complete CI/CD example.*