"Say you're building an app platform where the AI writes TypeScript for every tenant. Say you're running a CI/CD product where each repository has its own pipeline. Say you're using an agents SDK where each agent writes its own durable plan. In every one of these cases, the workflow is different for every tenant, every agent, every request. There is no single class to bind."
"Previously, Cloudflare Workflows required workflow code to be part of the deployment, one binding, one class, per deploy. Dynamic Workflows removes that constraint, letting a platform route every create() call to a different tenant's code and have the engine dispatch run(event, step) back to that same code when the workflow executes seconds, hours, or days later."
"A Worker Loader sits between the Workflows engine and the tenant's code (a Dynamic Worker), routing execution to the right tenant when the engine wakes up. When a tenant calls env.WORKFLOWS.create(...), it looks like a normal Workflow binding. Behind the scenes, the Worker Loader wraps the call with tenant metadata, the Workflows engine persists the payload, and when the engine later wakes to execute a step, the metadata routes execution back to the correct tenant's code."
"Workflow IDs, pause/resume, retries, hibernation, step.sleep('24 hours'), and step.waitForEvent() all work unchanged."
Dynamic Workflows is an MIT-licensed library that extends Cloudflare’s durable execution engine to allow workflow code to vary by tenant, agent, or request at runtime. Previously, workflow code had to be included in the deployment with one binding and one class per deploy. Dynamic Workflows removes that constraint by routing each create() call to the appropriate tenant’s code and dispatching run(event, step) back to the same code when execution resumes later. A Worker Loader sits between the engine and tenant code, wrapping create calls with tenant metadata, persisting the payload, and using metadata to route step execution. Workflow IDs, pause/resume, retries, hibernation, step.sleep, and step.waitForEvent continue to work unchanged.
Read at InfoQ
Unable to calculate read time
Collection
[
|
...
]