Cloudflare launches Dynamic Workflows, extending persistent execution to code that runs dynamically on a per-tenant and per-Agent basis. Cloudflare 发布 Dynamic Workflows，将持久化执行扩展到按租户与按 Agent 动态运行的代码

Cloudflare just quietly shipped a tool that could rewrite the rules of serverless multi-tenancy. Dynamic Workflows, an open-source MIT-licensed library, solves a problem that’s been nagging at the edges of edge computing for years: how do you handle long-running, stateful processes when the very code that defines the process is different for every single user, agent, or tenant? The answer, it turns out, is a elegantly simple 300-line TypeScript shim that feels like a cheat code.

Before this, Cloudflare Workflows—and frankly, most workflow engines—operated on a rigid deployment model. Your workflow logic was baked into a binding. You had one class, one definition, deployed as one immutable unit. You could parameterize the input to that workflow, but not the fundamental behavior itself. This works perfectly for a straightforward automation like “process this payment and then send an email.” It crumbles the moment you build a platform where the workflow is the product.

Imagine building an AI agent platform where each user can create their own custom agent with unique, persistent execution logic. Or a SaaS CI/CD tool where every customer has a wildly different deployment pipeline. Or, as Cloudflare engineers Dan Lapid and Luís Duarte pointed out, an application platform where a large language model generates bespoke TypeScript workflow code for each tenant. In these scenarios, there is no single, monolithic “workflow class” to bind to. The workflow is the dynamic, user-generated, or tenant-specific payload. The old model forces you into a terrible compromise: either sandbox each tenant into its own isolated, expensive deployment, or try to cram all the possible logic into one bloated, conditional nightmare. It’s a choice between cost/complexity explosion and architectural decay.

Dynamic Workflows elegantly sidesteps this dilemma. It introduces a Worker Loader—a thin, brilliant layer of indirection. When a tenant calls env.WORKFLOWS.create(), they’re not actually invoking their own code directly. They’re handing a request to a universal entry point that attaches crucial metadata (the tenantId, for instance) and persists it alongside the workflow’s state. When the workflow’s turn comes to execute, potentially hours or days later for a step.sleep('24 hours'), the engine doesn’t look for a pre-bound class. Instead, it consults the metadata, re-routes the request through the Loader, which then dynamically fetches and instantiates the correct, isolated worker containing that specific tenant’s code.

The magic isn’t in raw complexity, but in the profound shift in responsibility. The workflow engine becomes a universal scheduler and state machine, agnostic to the code it runs. The application logic becomes fluid, deployable, and updatable on a per-tenant basis without touching the engine itself. Your workflow definition can be literally generated on the fly, stored in a database, and fetched milliseconds before execution. This is the missing primitive for building true platform-as-a-service offerings on Cloudflare’s infrastructure, or any other, frankly.

It’s worth noting how this aligns with a broader, more philosophical shift in cloud architecture. We’re moving away from the era of “serverless functions as discrete compute units” and towards “serverless orchestration as a substrate.” The compute isn’t the scarce or interesting part anymore; it’s the coordination, the state, and the ability to embed complex, long-lived logic within ephemeral systems. Cloudflare is betting that the future isn’t just about running code at the edge, but about managing the intricate state machines that drive that code across distributed users and time.

The implementation details are clean. The entire library is tiny. It preserves all the powerful primitives of the core Workflows engine—retries, explicit sleep, event waiting, unique IDs—without modification. The developer experience looks straightforward from the sample code. This isn’t a heavy-handed, opinionated framework; it’s a minimalist toolkit that unlocks a new category of applications.

Of course, the real test will be in adoption and edge cases. How does this perform at scale with thousands of unique, dynamic workflows? What are the debugging implications when the code path is determined at runtime based on fetched modules? Security becomes paramount; a flaw in the loadTenant logic could have catastrophic cross-tenant consequences. But these are implementation challenges, not flaws in the core concept.

Competitively, this puts a clear stake in the ground. Temporal and AWS Step Functions are powerful, but they are fundamentally engines for coordinating known processes. They excel when you, the developer, define all possible workflow graphs. Cloudflare’s Dynamic Workflows is designed for a world where the process graph is a first-class, mutable data object. It’s a tool for building the platforms that will build the next generation of AI and developer tools.

In the end, this release is more than just a new library. It’s an acknowledgment that the most interesting problems in software aren’t about running a single function faster, but about orchestrating millions of unique, stateful journeys. Cloudflare just handed developers a very sharp, very precise tool for carving out that complexity. The apps we can now build just got a lot more interesting.

Cloudflare终于动了它那僵化已久的工作流引擎的手脚。新发布的Dynamic Workflows，虽然听起来只是个技术库的开源，但本质上是在补一个早就该补上的致命漏洞：它的上一代工作流，根本不懂“变化”为何物。

此前的Cloudflare Workflows，要求所有工作流代码必须作为部署单元静态绑定。每次部署，一个binding对应一个类，铁板一块。这在单一应用的世界里或许可行，但在今天这个AI、多租户、Agent遍地开花的时代，这种设计简直像要求所有乘客穿着统一制服、预定同一班次才能上火车。你为某个租户AI生成了一套代码，或者为某个项目仓库定义了一条独特的CI/CD流水线，你总不能每次有新租户、新仓库，就重新部署一次整个平台吧？旧架构的思路，根本没为“千人千面”的动态世界做好准备。

Dynamic Workflows的核心，就是在这堵静态墙中间，撬开了一道动态的缝。它巧妙地在Workflows引擎和租户代码之间，插入了一个轻量的“Worker Loader”。当租户调用 create() 时，这个Loader会悄悄附上“租户元数据”。等工作流在数小时或数天后被唤醒时，系统能凭借这些元数据，精准地“投递”回调，把请求路由回正确的租户代码。这300行TypeScript代码实现的，是一种解耦：工作流的“调度能力”和“执行代码”被彻底分开了。

最聪明的是，它保持了表面的平静。对开发者来说，env.WORKFLOWS.create(...) 看起来和以前一模一样，那些烦人的暂停、恢复、重试、24小时休眠、事件等待等能力全都原封不动。改动的全是底层路由逻辑，这大大降低了迁移和认知成本。Cloudflare的工程团队在博客里举的例子很到位：无论是AI为每个租户动态生成TypeScript的PaaS，还是每个Agent拥有独立执行计划的SDK，都需要这种“代码即数据”的动态绑定能力。他们本质上承认了一个事实：未来的工作流，其代码逻辑本身就是高度个性化、动态生成的数据。

但这里也埋下了一个值得警惕的点：当工作流的执行代码可以动态加载时，安全边界在哪里？租户A的代码如何确保不会意外或恶意地影响租户B的执行路径？Cloudflare依靠其Workers的隔离和沙箱机制来兜底，但将代码动态加载与持久化执行结合，无疑大幅增加了攻击面的复杂性。300行代码看似简洁，但它驾驭的是底下庞大且敏感的引擎。这是一个用极简接口包裹巨大复杂性的典型范例，其健壮性有待时间检验。

从更大的图景看，这是Cloudflare对其“边缘即平台”叙事的又一次强化。它不再满足于提供通用的计算和存储，而是在深入构建支撑下一代应用（尤其是AI原生应用）的特定基础设施。工作流引擎的动态化，直接瞄准了Agent SDK和自动化流水线这些最前沿的阵地。与那些从虚拟机或容器一路演进、包袱沉重的云厂商相比，Cloudflare有机会从更底层、更干净地设计适应新范式的组件。

所以，别小看这个开源库。它解决的不仅是技术限制，更是思维模式的转变。它意味着，Cloudflare开始认真对待“代码即临时工”的时代——代码不再是需要精心安装的固定资产，而是可以按需召唤、用完即走的动态资源。这种架构哲学，或许比功能本身更值得关注。当其他云平台还在围绕K8s和VM优化调度时，Cloudflare已经在为AI代理的自主执行铺设铁路了。