Introducing Dynamic Workflows: durable execution that follows the tenant

Dynamic Workflows extends Cloudflare’s durable execution system to multi-tenant and dynamically generated applications. While Dynamic Workers provide isolated runtime compute, Durable Object Facets provide tenant-specific storage, and Artifacts provide versioned source control, Dynamic Workflows lets each tenant supply its own long-running workflow code. The result is durable execution that can resume the correct tenant’s workflow after failures, hibernation, or delays of days.

The Gap Between Durable and Dynamic Execution

• Cloudflare Workflows turns a run(event, step) function into a durable program.
• Workflow steps can:
  • Survive isolate recycling and failures
  • Sleep for hours or days
  • Wait for external events
  • Resume from the exact point where execution stopped
• Workflows V2 supports up to 50,000 concurrent instances and 300 new instances per second per account.
• Traditional Workflows assume the workflow class is included in the deployment and statically configured in wrangler.jsonc.
• That model breaks for:
  • Multi-tenant SaaS platforms
  • AI-generated tenant applications
  • Repository-specific CI/CD pipelines
  • Agents that create their own durable plans
• In these systems, workflow code varies by tenant, agent, repository, or request, so a single statically bound class is insufficient.

Dynamic Workflows

• @cloudflare/dynamic-workflows is a roughly 300-line TypeScript library.
• It introduces a Worker Loader that:
  • Loads each tenant’s code dynamically
  • Routes workflow creation to the appropriate tenant
  • Ensures later workflow execution returns to that tenant’s code
• The Loader creates a dynamic Worker with:
  • A tenant-specific module
  • A TenantWorkflow entrypoint
  • A wrapped WORKFLOWS binding
• The dynamic entrypoint is registered as the workflow class in wrangler.jsonc.
• Tenant code remains ordinary Cloudflare Workflows code and does not need to know it is being dynamically dispatched.

Tenant Workflow Behavior

• Tenants can use the normal Workflow APIs, including:
  • env.WORKFLOWS.create(...)
  • Workflow IDs and .status()
  • .pause()
  • Retries and durable steps
  • step.sleep('24 hours')
  • step.waitForEvent()
• A tenant can define a standard WorkflowEntrypoint with a run(event, step) method.
• The library’s primary responsibility is preserving the association between a workflow instance and the tenant implementation when the workflow resumes later.

Three-Layer Execution Model

• Dynamic Workflows consists of three layers:
  • The Cloudflare Workflows engine
  • The platform’s Worker Loader
  • The tenant’s dynamically loaded Worker code
• A request first enters the Loader, which identifies the tenant and routes execution to its dynamic code.
• The workflow engine then persists the workflow state and later invokes run(event, step).
• The Loader resolves the correct tenant implementation when execution resumes, even after delays or failures.

Dynamic Workflows provides the missing durable-execution counterpart to Cloudflare’s dynamic compute, storage, and source-control primitives. It is particularly suited to platforms where customers or agents generate workflow code at runtime while still requiring standard durable guarantees.