In May 2026, InfoQ published Cloudflare Ships Dynamic Workflows, Bringing Durable Execution to Per-Tenant and Per-Agent Code, announcing that Cloudflare has released the Dynamic Workflows library under the MIT license. Built on Dynamic Workers, it enables dynamically swapping workflow code on a per-tenant, per-agent, or per-request basis, running millions of unique workflows with near-zero idle cost.
In multi-tenant SaaS development, how to handle "business logic that varies by tenant" is an enduring challenge. In this article, we outline design guidelines, cost structures, contractual clauses, and pitfalls for operating Dynamic Workflows in the context of custom client development.
What is new? Per-tenant durable execution
In traditional durable execution platforms (Temporal, AWS Step Functions, Inngest, etc.), workflow definitions consisted of static, pre-deployed code. Handling per-tenant branching required either sprawling if-statements or strategy patterns keyed on tenant IDs.
Dynamic Workflows introduces the following fundamental shifts:
| Item | Traditional durable execution | Dynamic Workflows |
|---|---|---|
| Workflow definition | Static, shared across all tenants | Dynamically swapped per tenant |
| Deployment unit | Entire application | A single tenant's single workflow |
| Idle cost | Incurs baseline costs for persistent containers | Near zero |
| Customization | Branching via strategy patterns | Direct deployment of tenant-specific code |
| Scale | Dozens to hundreds of workflows | Millions of unique variants |
In particular, the ability to "directly deploy tenant-specific code" directly aligns with the reality of client development, where "every client has a distinct business process." This elevates the philosophy of "running code dynamically" explored in MCP Token Optimization with Cloudflare Code Mode up to the workflow layer.
Typical pain points in multi-tenant client SaaS
In custom SaaS development, the following requests surface time and again:
| Client pain point | Problem with the legacy approach |
|---|---|
| An enterprise client requests: "Our company needs a three-stage internal approval flow." | If-statements proliferate across the codebase, destroying maintainability |
| Notification timing varies by industry | Tenant configuration JSONs bloat, making comprehensive test coverage impractical |
| "We integrate with this specific SaaS, while another client uses that API." | Every third-party SDK is bundled together, inflating build sizes |
| The client wants isolated SLAs for custom features | Single-cluster setups cannot isolate workloads, causing noisy-neighbor issues |
Dynamic Workflows provides a simple solution to all of these challenges: "deploying tenant-dedicated code." On the custom development frontline, the ability to "map the degree of customization directly to contractual fees" is a massive advantage.
Four-tier workflow design for client development
When integrating Dynamic Workflows into client projects, structuring the architecture into four tiers based on change frequency and blast radius brings immense clarity.
[Tier 0: コア共通ロジック]
├ 認証・認可・課金・ロギング
├ 全テナント共通・SLA 99.95%
└ 変更は四半期に 1 回
[Tier 1: 業界別テンプレート]
├ EC / 医療 / 金融 / 製造の標準フロー
├ 同業界の複数テナントが共有
└ 変更は月次
[Tier 2: テナント別カスタム]
├ 顧客固有の承認フロー・通知
├ Dynamic Workflows で個別配置
└ 変更は週次〜随時
[Tier 3: テナント別エージェント]
├ 顧客固有の AI エージェント挙動
├ プロンプト・モデル選択・接続先 MCP
└ 変更は日次In particular, Tier 2 and Tier 3 have historically been areas where maintenance tended to break down even when agreed upon in contracts. Because Dynamic Workflows provides an "isolated runtime for each tenant," it delivers the operational advantage of "shipping changes without the risk of impacting other tenants."
This represents isolation of the execution logic tier, serving as the counterpart to data tier isolation discussed in Multi-Tenant Design with PostgreSQL RLS. By pairing both together, you can satisfy SOC 2 and ISO 27001 tenant isolation requirements across both code and data.
Cost model: The disruptive power of near-zero idle cost
The cost model of Dynamic Workflows has the potential to fundamentally transform estimation structures in client development.
| Item | Legacy (Temporal Cloud / Step Functions) | Dynamic Workflows |
|---|---|---|
| Monthly idle cost | Tenants × persistent worker infrastructure costs | Near zero |
| Execution cost | Per state transition | Requests + execution duration |
| Startup latency | From several seconds (worker cold start) | Dozens of milliseconds (Workers cold start) |
| Cost to add a tenant | Scales linearly | Active usage only |
The benefits are especially pronounced in "business SaaS that sees virtually no traffic at night or on weekends." Whereas legacy architectures incur mounting persistent worker fees proportional to the total tenant count, Dynamic Workflows charges only for incoming requests. Because savings vary considerably depending on tenant numbers, active operating windows, and per-execution runtimes, teams should calculate projections against baseline metrics from their existing setup.
This pushes beyond the "usage-based billing" discussed in Claude Code Operational Cost Optimization 2026, establishing an architecture that "shifts the entire infrastructure to an actual-usage basis."
"Multi-tenant workflow clauses" to include in client contracts
Here are key clauses that should be explicitly stipulated in contracts when incorporating Dynamic Workflows into client engagements.
| Clause | Details | What the client should verify |
|---|---|---|
| Tier classification | Boundaries across core, template, tenant, and agent layers | Whether a client customization falls under Tier 2 or Tier 3 |
| Deployment permissions | Who can modify Tier 2/3 code | Whether modifications can be executed by the client |
| Testing responsibility | Responsibility for Tier 2/3 test coverage | Availability of staging environments |
| Incident blast radius | Guarantee that outages in one tenant will not cascade to others | Unit of SLA calculation |
| Cost allocation | Method for tracking actual costs per tenant | Granularity of monthly reporting |
| Agent behavior limits | LLM call counts and token ceilings | Monthly budget alerts |
In particular, regarding the "blast radius during incidents," leveraging Dynamic Workflows' "tenant-isolated runtimes" allows you to draft contract clauses specifying that "an outage in Tenant A does not impact Tenant B for SLA calculation purposes." This represents a groundbreaking provision that could never be written under conventional single-cluster SaaS contracts.
Five common pitfalls
Finally, here are common pitfalls to watch out for when operating Dynamic Workflows in client projects.
Pitfall 1: Tier 2 bloating into a "pseudo-fork"
Just because you can deploy tenant-specific code does not mean you should "write everything in Tier 2," as that simply recreates the maintenance nightmare of managing separate code forks. Review Tier 1 templates every six months to backport reusable patterns originating in Tier 2.
Pitfall 2: Debugging per-tenant runtimes is difficult
Investigating issues where "only Tenant A fails" is inherently more complex than debugging shared codebase logic. Always instrument structured logging containing tenant IDs alongside distributed tracing inside Tier 0.
Pitfall 3: Overlooking testing costs behind zero idle costs
While runtime costs remain low, running CI test suites across every single tenant is a separate financial burden. Scope tested tenants on a contractual basis and design a rotating monthly test schedule.
Pitfall 4: Agent behavior budgets are easy to exceed
Introducing tenant-specific LLM behaviors in Tier 3 risks scenarios where aberrant calls from a single tenant drain the entire monthly budget. Always enforce per-tenant monthly token limits in Tier 0.
Pitfall 5: Accelerating Cloudflare lock-in
Dynamic Workflows is proprietary to Cloudflare. Because "migrating workflows to another cloud" incurs non-linear costs, include a clause stating "portability is not guaranteed" to ensure clear alignment with the client.
Conclusion: Making "per-tenant code" the standard in client development
Cloudflare Dynamic Workflows offers a powerful answer to the "customization versus maintainability dilemma" in multi-tenant SaaS. In client development, the ability to "sustainably maintain client-specific customizations" directly translates into higher retention and client satisfaction.
However, before deciding whether to adopt it, you must first establish the boundary of which customizations belong in Tier 1 templates and which cross over into Tier 2. The answer depends on tenant counts, customization overlap, and how deeply conditional branches are embedded in existing code, which in turn dictates the team structure and timeline required. If you are planning to transition an existing SaaS to a multi-tenant model and want to define these boundaries together, please reach out through our contact form. Having visibility into which files currently contain tenant-specific branching will allow our initial discussion to start from a much deeper level.
