Add dynamic workflows, backed by encrypted ref storage

[pranaygp]

RFC: #2063
Server support: https://github.com/vercel/workflow-server/pull/917

Summary

Allow applications to start durable workflows from JavaScript source when the orchestration is only known at runtime—for example, workflow builders, customer automations, and generated plans over a fixed catalog of deployed steps.

const run = await start(source, [input], {
  experimental_dynamic: {
    steps: { fetchUser, sendEmail },
  },
});

Only orchestration is dynamic. Step implementations must already be deployed, and experimental_dynamic.steps selects the aliases available to the source.

Design

• Parse source and the generated wrapper without evaluating it, using an ECMAScript 2024 grammar compatible with the supported Node 22 runtime.
• Derive a stable workflow ID from source plus canonical step bindings.
• Preflight exact backend and target-runtime capability versions before durable or executable start side effects.
• Serialize, conditionally compress, and encrypt generated code through the run-payload pipeline; replay uses the stored definition rather than the deployment bundle.
• Keep dynamic Node compilation out of the shared static workflow script cache.
• Carry code or its deferred ref through normal, turbo, and resilient-start paths.
• Store only a small plaintext identity marker in executionContext.dynamicWorkflow; enforce the Vercel backend's 2,048-byte JSON UTF-8 limit before writes.
• Persist source on the run, not lifecycle events, and remove it under zero retention in local and Postgres Worlds.
• Hydrate code for CLI and web inspection while preserving encrypted placeholders until decryption.
• Reject Replay Run cloning for dynamic runs and disable the action in the UI.

Dynamic source is trusted application code. The workflow VM provides deterministic replay, not a security boundary for hostile JavaScript.

World support

• world-vercel: encrypted, ref-backed storage through the paired server PR; small definitions travel inline in the creation frame and larger definitions upload first.
• world-local: stored on the filesystem run record.
• world-postgres: stored in dynamic_workflow_code_cbor.
• Worlds that do not attest support fail before creating or queueing a dynamic run.

Test Plan

• Focused Core, World, Web, parser, retention, replay, schema, and hydration suites pass locally.
• Generated wrappers compile on Node 22; focused QuickJS suites pass.
• Source-shape, wrapper-collision, syntax-version, alias, cache-isolation, capability, execution-context, and no-side-effect regressions are included.
• Deployment-dependent dynamic E2E requires the paired server capability/storage preview.

Docs Preview

The Dynamic Workflows page and start() API reference are included. A preview URL is currently unavailable because Vercel Labs deployment is blocked by Protected Git Scope configuration.

[vercel]

The latest updates on your projects. Learn more about Vercel for GitHub.

Project	Deployment	Actions	Updated
example-nextjs-workflow-turbopack	Ready	Preview, v0	Sep 29, 2026 12:57am UTC
example-nextjs-workflow-webpack	Ready	Preview, v0	Sep 29, 2026 12:57am UTC
example-workflow	Ready	Preview, v0	Sep 29, 2026 12:57am UTC
workbench-astro-workflow	Ready	Preview, v0	Sep 29, 2026 12:57am UTC
workbench-express-workflow	Ready	Preview, v0	Sep 29, 2026 12:57am UTC
workbench-fastify-workflow	Ready	Preview, v0	Sep 29, 2026 12:57am UTC
workbench-hono-workflow	Ready	Preview, v0	Sep 29, 2026 12:57am UTC
workbench-nestjs-workflow	Ready	Preview, v0	Sep 29, 2026 12:57am UTC
workbench-nitro-workflow	Ready	Preview, v0	Sep 29, 2026 12:57am UTC
workbench-nuxt-workflow	Ready	Preview, v0	Sep 29, 2026 12:57am UTC
workbench-python-workflow	Ready	Preview, v0	Sep 29, 2026 12:57am UTC
workbench-sveltekit-workflow	Ready	Preview, v0	Sep 29, 2026 12:57am UTC
workbench-tanstack-start-workflow	Ready	Preview, v0	Sep 29, 2026 12:57am UTC
workbench-vite-workflow	Ready	Preview, v0	Sep 29, 2026 12:57am UTC
workflow-docs	Ready	Preview, v0	Sep 29, 2026 12:57am UTC
workflow-swc-playground	Ready	Preview, v0	Sep 29, 2026 12:57am UTC
workflow-tarballs	Ready	Preview, v0	Sep 29, 2026 12:57am UTC
workflow-web	Ready	Preview, v0	Sep 29, 2026 12:57am UTC

[changeset-bot]

🦋 Changeset detected

Latest commit: 7c1bcd4

The changes in this PR will be included in the next version bump.

This PR includes changesets to release 21 packages

Name	Type
@workflow/core	Minor
@workflow/world	Minor
@workflow/world-vercel	Minor
@workflow/world-local	Minor
@workflow/world-postgres	Minor
@workflow/web-shared	Minor
@workflow/cli	Minor
workflow	Minor
@workflow/builders	Patch
@workflow/next	Patch
@workflow/nitro	Patch
@workflow/vitest	Patch
@workflow/web	Minor
@workflow/world-testing	Patch
@workflow/errors	Patch
@workflow/astro	Patch
@workflow/nest	Patch
@workflow/rollup	Patch
@workflow/sveltekit	Patch
@workflow/vite	Patch
@workflow/nuxt	Patch

Not sure what this means? Click here to learn what changesets are.

Click here if you're a maintainer who wants to add another changeset to this PR

[github-actions]

🧪 E2E Test Results

✅ All tests passed

⚠️ Flaky E2E Tests (passed on retry)

These tests failed at least once and passed on a retry. A recurring entry here is a real race worth investigating.

• readableStreamWorkflow (example · vercel-prod / vercel / quickjs / production) — flaked in 2 jobs
• health check (CLI) - workflow health command reports healthy endpoints (express · local-dev / local / node / stable)
• multiple sequential tool calls (nextjs-webpack · vercel-prod / vercel / node / production)
• spawnWorkflowFromStepWorkflow - spawning a child workflow using start() inside a step (nuxt · local-dev / local / node / stable)

🛠 Infra Events (absorbed by the harness)

Platform anomalies the e2e harness detected and worked around (e.g. a run the queue never picked up, replaced by a fresh run). Clustered timestamps indicate a backend blip; a steady drip indicates a platform issue worth escalating.

• run-pickup-stall · runs app-generated source against a registered step (tanstack-start) · at 00:57:45Z · abandoned wrun_01M3NANCWW59HMBWX14GSCZHHR
• cold-start-warmup · suite warmup (tanstack-start) · at 00:57:53Z · abandoned wrun_01M3NANCW41Z20CBED4YYY25M4
• run-pickup-stall · hookCleanupTestWorkflow - hook token reuse after workflow completion (nextjs-webpack) · at 01:02:54Z · abandoned wrun_01M3NAYT929DPDCCS0AW1EMZ8F
• run-pickup-stall · customSerializationWorkflow - custom class serialization with WORKFLOW_SERIALIZE/WORKFLOW_DESERIALIZE (nextjs-webpack) · at 01:04:18Z · abandoned wrun_01M3NB1C64S6FSMV9TY8QDAWKN

E2E Test Summary

Summary

	Passed	Failed	Skipped	Total
✅ ▲ Vercel Production	3904	0	875	4779
✅ 💻 Local Development	4406	0	550	4956
✅ 📦 Local Production	4406	0	550	4956
✅ 🐘 Local Postgres	4406	0	550	4956
✅ 🪟 Windows	342	0	12	354
✅ 🌐 Cross-language Conformance	68	0	84	152
✅ dynamic-runs	0	0	0	0
✅ vercel-http-transport	879	0	183	1062
✅ vercel-multi-region	27	0	0	27
✅ vercel-ws-transport	595	0	113	708
Total	19033	0	2917	21950

Details by Category

✅ ▲ Vercel Production

App	Passed	Failed	Skipped
✅ astro-node	142	0	35
✅ astro-quickjs	142	0	35
✅ example-node	142	0	35
✅ example-quickjs	142	0	35
✅ express-node	142	0	35
✅ express-quickjs	142	0	35
✅ fastify-node	142	0	35
✅ fastify-quickjs	142	0	35
✅ hono-node	142	0	35
✅ hono-quickjs	142	0	35
✅ nest-node	142	0	35
✅ nest-quickjs	142	0	35
✅ nextjs-turbopack-node	169	0	8
✅ nextjs-turbopack-quickjs	169	0	8
✅ nextjs-webpack-node	169	0	8
✅ nextjs-webpack-quickjs	169	0	8
✅ nitro-node	142	0	35
✅ nitro-quickjs	142	0	35
✅ nuxt-node	142	0	35
✅ nuxt-quickjs	142	0	35
✅ python-node	66	0	111
✅ sveltekit-node	161	0	16
✅ sveltekit-quickjs	161	0	16
✅ tanstack-start-node	142	0	35
✅ tanstack-start-quickjs	142	0	35
✅ vite-node	142	0	35
✅ vite-quickjs	142	0	35

✅ 💻 Local Development

App	Passed	Failed	Skipped
✅ astro-stable-node	148	0	29
✅ astro-stable-quickjs	148	0	29
✅ express-stable-node	148	0	29
✅ express-stable-quickjs	148	0	29
✅ fastify-stable-node	148	0	29
✅ fastify-stable-quickjs	148	0	29
✅ hono-stable-node	148	0	29
✅ hono-stable-quickjs	148	0	29
✅ nest-stable-node	148	0	29
✅ nest-stable-quickjs	148	0	29
✅ nextjs-turbopack-canary-node	176	0	1
✅ nextjs-turbopack-canary-quickjs	176	0	1
✅ nextjs-turbopack-stable-node	176	0	1
✅ nextjs-turbopack-stable-quickjs	176	0	1
✅ nextjs-webpack-canary-node	176	0	1
✅ nextjs-webpack-canary-quickjs	176	0	1
✅ nextjs-webpack-stable-node	176	0	1
✅ nextjs-webpack-stable-quickjs	176	0	1
✅ nitro-stable-node	148	0	29
✅ nitro-stable-quickjs	148	0	29
✅ nuxt-stable-node	148	0	29
✅ nuxt-stable-quickjs	148	0	29
✅ sveltekit-stable-node	167	0	10
✅ sveltekit-stable-quickjs	167	0	10
✅ tanstack-start-node	148	0	29
✅ tanstack-start-quickjs	148	0	29
✅ vite-stable-node	148	0	29
✅ vite-stable-quickjs	148	0	29

✅ 📦 Local Production

App	Passed	Failed	Skipped
✅ astro-stable-node	148	0	29
✅ astro-stable-quickjs	148	0	29
✅ express-stable-node	148	0	29
✅ express-stable-quickjs	148	0	29
✅ fastify-stable-node	148	0	29
✅ fastify-stable-quickjs	148	0	29
✅ hono-stable-node	148	0	29
✅ hono-stable-quickjs	148	0	29
✅ nest-stable-node	148	0	29
✅ nest-stable-quickjs	148	0	29
✅ nextjs-turbopack-canary-node	176	0	1
✅ nextjs-turbopack-canary-quickjs	176	0	1
✅ nextjs-turbopack-stable-node	176	0	1
✅ nextjs-turbopack-stable-quickjs	176	0	1
✅ nextjs-webpack-canary-node	176	0	1
✅ nextjs-webpack-canary-quickjs	176	0	1
✅ nextjs-webpack-stable-node	176	0	1
✅ nextjs-webpack-stable-quickjs	176	0	1
✅ nitro-stable-node	148	0	29
✅ nitro-stable-quickjs	148	0	29
✅ nuxt-stable-node	148	0	29
✅ nuxt-stable-quickjs	148	0	29
✅ sveltekit-stable-node	167	0	10
✅ sveltekit-stable-quickjs	167	0	10
✅ tanstack-start-node	148	0	29
✅ tanstack-start-quickjs	148	0	29
✅ vite-stable-node	148	0	29
✅ vite-stable-quickjs	148	0	29

✅ 🐘 Local Postgres

App	Passed	Failed	Skipped
✅ astro-stable-node	148	0	29
✅ astro-stable-quickjs	148	0	29
✅ express-stable-node	148	0	29
✅ express-stable-quickjs	148	0	29
✅ fastify-stable-node	148	0	29
✅ fastify-stable-quickjs	148	0	29
✅ hono-stable-node	148	0	29
✅ hono-stable-quickjs	148	0	29
✅ nest-stable-node	148	0	29
✅ nest-stable-quickjs	148	0	29
✅ nextjs-turbopack-canary-node	176	0	1
✅ nextjs-turbopack-canary-quickjs	176	0	1
✅ nextjs-turbopack-stable-node	176	0	1
✅ nextjs-turbopack-stable-quickjs	176	0	1
✅ nextjs-webpack-canary-node	176	0	1
✅ nextjs-webpack-canary-quickjs	176	0	1
✅ nextjs-webpack-stable-node	176	0	1
✅ nextjs-webpack-stable-quickjs	176	0	1
✅ nitro-stable-node	148	0	29
✅ nitro-stable-quickjs	148	0	29
✅ nuxt-stable-node	148	0	29
✅ nuxt-stable-quickjs	148	0	29
✅ sveltekit-stable-node	167	0	10
✅ sveltekit-stable-quickjs	167	0	10
✅ tanstack-start-node	148	0	29
✅ tanstack-start-quickjs	148	0	29
✅ vite-stable-node	148	0	29
✅ vite-stable-quickjs	148	0	29

✅ 🪟 Windows

App	Passed	Failed	Skipped
✅ nextjs-turbopack-node	171	0	6
✅ nextjs-turbopack-quickjs	171	0	6

✅ 🌐 Cross-language Conformance

App	Passed	Failed	Skipped
✅ python	68	0	84

✅ dynamic-runs

App	Passed	Failed	Skipped
✅ astro-vercel	0	0	0
✅ example-vercel	0	0	0
✅ express-vercel	0	0	0
✅ fastify-vercel	0	0	0
✅ hono-vercel	0	0	0
✅ nest-vercel	0	0	0
✅ nextjs-turbopack-vercel	0	0	0
✅ nextjs-webpack-vercel	0	0	0
✅ nitro-vercel	0	0	0
✅ nuxt-vercel	0	0	0
✅ sveltekit-vercel	0	0	0
✅ tanstack-start-vercel	0	0	0
✅ vite-vercel	0	0	0

✅ vercel-http-transport

App	Passed	Failed	Skipped
✅ example	142	0	35
✅ express	142	0	35
✅ hono	142	0	35
✅ nextjs-turbopack	169	0	8
✅ nitro	142	0	35
✅ vite	142	0	35

✅ vercel-multi-region

App	Passed	Failed	Skipped
✅ nextjs-turbopack	27	0	0

✅ vercel-ws-transport

App	Passed	Failed	Skipped
✅ example	142	0	35
✅ express	142	0	35
✅ nextjs-turbopack	169	0	8
✅ vite	142	0	35

---

📋 View full workflow run

[github-actions]

📊 Workflow Benchmarks

commit 7c1bcd4 · Tue, 29 Sep 2026 01:20:28 GMT · run logs

Backend: vercel · app: nextjs-turbopack

Metric	Scenario	Best (ms)	P75 (ms)	P90 (ms)	P99 (ms)	Samples
TTFS	step	2354 (+554%) 🔻	2527 🔴 (+36%) 🔻	2581 🔴 (+38%) 🔻	2985 🔴 (+40%) 🔻	30
TTFS	stream	2073 (+327%) 🔻	2541 🔴 (+18%) 🔻	2593 🔴 (+17%) 🔻	2726 🔴 (+17%) 🔻	30
TTFS	hook + stream	2718 (+282%) 🔻	2856 🔴 (+29%) 🔻	2908 🔴 (+23%) 🔻	3112 🔴 (+23%) 🔻	30
Fan-out TTFS	Promise.all(100 steps)	736 (+30%) 🔻	1033 (-25%) 💚	2923 (+33%) 🔻	3063 (+27%) 🔻	10
Fan-out TTLS	Promise.all(100 steps)	2164 (+34%) 🔻	3448 (-5.1%)	4269 (+16%) 🔻	10895 (+110%) 🔻	10
STSO	1020 steps (inline)	157 (+31%) 🔻	182 (+17%) 🔻	198 (+18%) 🔻	257 (-1.2%)	1019
WO	1020 steps	182438 (+21%) 🔻	182438 (+21%) 🔻	182438 (+21%) 🔻	182438 (+21%) 🔻	1
CRTT	first chunk (pooled)	72 (+4.3%)	126 (-7.4%)	204 (+14%)	287 (+44%) 🔻	28

Streams

Scenario	CRTT 1st	p75	p90	p99	CDV max	iters
paced control (100/s, 60B)	111 (+6%)	173 (-7%)	222 (-34%)	299 (-46%)	117 (-46%)	10
size sweep (100/s, 160B-12KB)	119 (+10%)	175 (-19%)	204 (-59%)	296 (-57%)	133 (-56%)	10
replay gateway-gpt-5.4-nano-2000t (1x)	113 (-24%)	167 (-17%)	191 (-35%)	356 (-55%)	215 (-55%)	3
replay eve-gpt-5.6-sol-2000t (1x)	111 (-33%)	142 (-23%)	179 (-29%)	414 (-68%)	281 (-62%)	2
replay eve-gpt-5.6-sol-2000t (2x)	91 (-21%)	207 (-24%)	252 (-44%)	465 (-69%)	179 (-73%)	3

📈 STSO distribution vs main (inline / queue-hop histograms)

1020 steps (inline)

Cumulative STSO time: main 150825ms → this run 182072ms (Δ +31247ms, +21%)

100-150 ms  ┃█████████████████        main 713  this   0  -713
150-200 ms  ███████░░░░░░░░░░░░░░░░┃  main 268  this 927  +659
200-250 ms  █┃                        main  25  this  77   +52
250-300 ms  ┃                         main  11  this  11    +0
300-350 ms  ┃                         main   1  this   1    +0
400-450 ms  ┃                         main   1  this   2    +1
450-500 ms  ┃                         main   0  this   1    +1

📈 CRTT drill-down vs main (RTT distributions & profiles)

variant  RTT 1ms→5s+             avg         p50         p90         p99     n
control  ······▁█▁····  144.3 (-10%)   140 (-5%)  222 (-34%)  299 (-46%)  3000
sweep    ······▂█▁····  140.6 (-20%)  129 (-12%)  204 (-59%)  296 (-57%)  3000
gw 1x    ······▂█▁····  135.9 (-23%)   142 (±0%)  191 (-35%)  356 (-55%)  5295
eve 1x   ·····▁▅█▁▁···  120.9 (-29%)  107 (-22%)  179 (-29%)  414 (-68%)  5186
eve 2x   ·····▁▂█▂▁···  151.4 (-28%)  130 (-24%)  252 (-44%)  465 (-69%)  7779

RTT over stream progress (avg per tenth of stream, bars scaled min→max):

control  ▇▄▃▃▁▃▄▁█▃  135–160ms
sweep    █▅▅▁▃▄▃█▃▃  127–155ms
gw 1x    ▄▄▅▃▃█▅▂▃▁  126–151ms
eve 1x   ▄▁▂▃▂█▆▃▇▁  110–140ms
eve 2x   ▃▁▂▂▂▆▅█▅▄  126–188ms

RTT by chunk size (avg per log size bin, ~160B → ~12KB serialized, bars scaled min→max):

sweep  ▄█▃▆▆▁▁  139–142ms

Delivery jitter over stream progress (avg positive CDV per tenth of stream, bars scaled min→max):

control  ▃▃▄▅▃▄▃▁█▆  43–58ms
sweep    ▁▄▄▄▆▂▇█▄▅  54–68ms
gw 1x    ▆▆▆▁▅█▄▄▂▃  36–51ms
eve 1x   ▅▅▄▄▆▇█▁▄▂  20–29ms
eve 2x   ▆▅▁▅▆▆▃▁▅█  21–29ms

ℹ️ Metric definitions & methodology

_{Streams: first-chunk RTT (the stream-open path, before any buffering/backpressure), CRTT percentiles, and worst delivery stall (CDV max). Cells are medians across iterations; per-run values in the artifacts. No 🔴/🟢 marks until targets attach.}

_{The collapsed STSO distribution section above buckets every step gap, split inline (same warm process — pure framework overhead) vs queue-hop (fresh process — dispatch, reinit, replay). █ = main, ┃ = this run, ░ = fill.}

_{The collapsed CRTT drill-down: per-variant RTT histograms (fixed log bins, · = empty) and mean RTT/positive-CDV profile lines over stream progress and chunk size. Histograms, avgs, and profiles merge exactly across runs; p50–p99 are percentile-of-percentiles. Per-index rows live in the artifacts.}

_{Best/P75/P90/P99 deltas compare against the most recent benchmark run on main at the time of this run. 🔻 flags a delta worse than +15%, 💚 one better than −15%.}

_{Metrics — TTFS: time to first step body (in-deployment start() → first step body) · Fan-out TTFS: fan-out time to first step (in-deployment start() → first of the parallel step bodies to complete) · Fan-out TTLS: fan-out time to last step (in-deployment start() → last of the parallel step bodies to complete, i.e. when the Promise.all resolves) · STSO: step-to-step overhead (gap between consecutive step bodies) · WO: workflow overhead (whole-run time outside step bodies, in-deployment anchored) · CRTT: chunk round-trip time (per-chunk write → read latency, one clock domain: deployment → stream backend → same deployment) · CDV: chunk delay variation / delivery jitter (inter-arrival gap minus inter-write gap per seq-adjacent pair; skew-free; the row is each run's MAX positive value, so one stall moves it)}

_{Scenarios — step: one trivial no-op step, no stream; no hooks, so the run stays in turbo mode (in-process fast path) · stream: one streaming step; no hooks, so the run stays in turbo mode (in-process fast path) · hook + stream: registers a hook before one step, which exits turbo mode (dispatch path) · 1020 steps: 1020 trivial sequential steps; STSO is measured between consecutive steps in the given step ranges, and WO is the whole-run overhead outside step bodies · Promise.all(100 steps): 100 trivial no-op steps started together in a single Promise.all; Fan-out TTFS is the first of them to complete and Fan-out TTLS the last, both from the in-deployment clientStart, so their gap is the spread the runtime adds across the fan-out · paced control (100/s, 60B): the control: 300 tiny (~60B) deltas metronome-paced at 100/s — zero workload structure, so it reads the transport floor and flush cadence, and disambiguates transport-wide vs workload-specific when a replay row moves · size sweep (100/s, 160B-12KB): same pacing as the control with deltas padded in rotation across seven log-spaced sizes (~160B–12KB) — rotation decouples size from stream position, so it isolates whether chunk size causes latency · replay gateway-gpt-5.4-nano-2000t (1x): raw provider SSE cadence captured at the AI gateway boundary (gpt-5.4-nano, the most popular gateway model; per-token deltas p50 208B = the modal production chunk size), replayed exactly as measured — the typical customer's workload; its CDV is the typical customer's real delivery jitter · replay eve-gpt-5.6-sol-2000t (1x): a captured eve turn (gpt-5.6-sol, the most-used demanding eve model; ~2000 output tokens = production p50 turn length) replayed exactly as measured — eve's envelope protocol re-ships the cumulative message so sizes ramp 142B→13KB; the demanding outlier tenant's reality · replay eve-gpt-5.6-sol-2000t (2x): the same eve capture at 2x — the headroom/stress row; real fast-tier models emit the same chunk sizes at proportionally higher rate, so time compression is a faithful speed model · first chunk (pooled): every run's seq-0 RTT pooled across all stream scenarios — the first chunk precedes any workload differentiation, so pooling samples one shared stream-open path with exact percentiles}

_{Replay cadences (semantic sha256) — eve-gpt-5.6-sol-2000t eaf22f5946e7c61f3c65c7006d550df180cfabd4e706254a09f22aec0cfb420d · gateway-gpt-5.4-nano-2000t 6f24ac518b6b83ff1d0e85a5fe78230db192716d66a7fc6b2fe022752001d041}

_{🔴 marks a percentile over its target (within target is left unmarked). Targets (p75/p90/p99, ms) — TTFS 200/300/600}

_{All timestamps are deployment-side; runs are triggered in-deployment, so the CI runner and api.vercel.com sit outside every measured window. TTFS = start() → first step body (includes dispatch + any cold start); Fan-out TTFS/TTLS = first/last step completion of one Promise.all from the same anchor (the gap is the runtime’s fan-out spread); STSO/WO between step bodies; CRTT inside the workflow (excludes the api.vercel.com read path).}

_{Cold starts stay in the numbers (real bursty-workload latency, inflates P75+); Best is the warm floor.}

[TooTallNate]

AI: Re-review verdict: Request changes. The current SDK head is unchanged from my previous review. I reran the targeted probe through the built SDK and confirmed that the existing queue-name finding still produces one run-creation write and zero queue calls before rejecting $workflow. Please validate the generated queue name before durable start side effects, or encode/restrict the export-name component appropriately. I updated the existing inline thread rather than duplicating it. The previously passing build and 760 focused tests apply to this same unchanged head; I did not rerun that entire set or deployed E2E in this pass.

[alangenfeld]

agh my bad on hitting re-request review too early, fixes inbound

[TooTallNate]

AI: Re-review verdict: Approve. Reviewed the queue-name fix and the rebased dynamic-workflow integration, including the interaction with cached cross-deployment capability probes. The remaining queue-name blocker is fixed: invalid export names reject before upload/create/queue, and the queue destination is validated up front for both static and dynamic starts. Valid $-prefixed step aliases remain supported. I found no new blocking issues and resolved the existing inline thread.

Validation: pnpm build passed (28 tasks); all 807 tests in 15 focused suites passed, covering dynamic compilation/start, cross-deployment spec/capability handling, serialization, replay/cache behavior, World schemas, local retention, and UI hydration/replay guards. Direct probes against the rebuilt SDK confirmed zero side effects for $workflow and successful creation/queueing with a $ step alias. Deployed E2E was not run in this pass.

[pranaygp]

Security review: blocking issues found (recommend request changes)

This review covers security and the effect on existing code paths. Three repros, run against d3e963405, all pass. That means each one shows the gap is real:

1. hydrateDynamicWorkflowCode(plaintextBytes, realRunKey) returns the plaintext code. Unencrypted code is accepted even when the run has a key.
2. Dynamic source run via runWorkflow reaches the host: steps.x.constructor.constructor("return process")() returns the real process, including env and getBuiltinModule.
3. Source can call globalThis[Symbol.for("WORKFLOW_USE_STEP")]("step//…/anyStep"), a step that was never passed in steps.

The docs already say (2) and (3) are not a boundary. The problem is (1) plus the missing opt-in: together they mean every existing deployment that upgrades the SDK will run arbitrary code from any run marked dynamic, without enabling anything. See the inline comments.

How it works (for reviewers)

start(source, args, { experimental_dynamic: { steps } })
  → acorn-parse (not evaluated) → wrapper registers workflow//dynamic/<sha256[:32]>//<export>
  → executionContext.dynamicWorkflow = { version, sourceHash, exportName, steps }  (plaintext)
  → code = encrypt(compress(devalue(wrapper))) → inline on run_created + queue runInput, or uploaded as a ref
delivery: if executionContext.dynamicWorkflow → hydrate stored code → compile once per invocation → replay
          else → deployment bundle (unchanged)

Also (no inline anchor)

• Observability: start() sets workflow.dynamic.* span attributes, but the delivery path records nothing when it executes stored code instead of the bundle. For an experimental code-execution feature, please add workflow.dynamic=true and source_hash to the delivery span, plus a one-time log per invocation, so security can audit it.
• Postgres / local Worlds store the code in plaintext. Write access to the DB or filesystem now means code execution on every worker, not just "start an existing workflow". Please document this next to the migration.
• Missing tests: replay rejects plaintext or sealed code when a key exists; a deployment without the opt-in refuses dynamic runs; a static run with a forged dynamicWorkflow marker fails the run instead of retrying forever; resolveData: 'none' doesn't return code.
• Nit: executionContext.dynamicWorkflow.steps exposes the alias → step//module//fn map in plaintext to anyone with read access. Worth one sentence in the docs, since they present it as an audit aid.

The earlier review findings still apply and aren't repeated here: missing or corrupt code makes delivery retry forever instead of failing the run; the capabilities 404 isn't mapped to {}, so the Vercel Prod E2E jobs are red; the 2 KB marker holds only about 30 aliases and that limit isn't documented; resolveData: 'none' still returns the code.

Recommendation: request changes. The minimum for shipping this as experimental without widening existing users' exposure is an opt-in on the executing deployment plus encr-only stored code.

[pranaygp]

Blocking: no opt-in on the executing deployment.

Whether a delivery runs the deployment bundle or stored code depends only on executionContext.dynamicWorkflow, a plaintext, caller-supplied field. The code itself comes from run.dynamicWorkflowCode, or on the turbo path from runInput.dynamicWorkflowCode in the queue message. Nothing on the deployment says "I accept dynamic code".

The VM can be escaped (steps.x.constructor.constructor("return process")()) and steps can be bypassed via Symbol.for("WORKFLOW_USE_STEP"). So the ability to start a workflow on deployment D becomes the ability to run arbitrary Node in D's functions: every env var (including values that are otherwise write-only), network, and any step with any arguments. Before this PR, the same principals could only start workflows D already had.

That applies to every deployment that upgrades, whether or not it uses the feature.

Suggested fix: make it opt-in on the executing deployment (a build or config flag, default off). Only advertise dynamicWorkflowVersion in the health check when it's on, and have this function fail the run (not throw to the queue) when a dynamic run reaches a deployment that hasn't opted in. It would also be reasonable to limit the first release to same-deployment starts.

[pranaygp]

Blocking (same root cause as runtime.ts:728). Every deployment on this SDK unconditionally tells cross-deployment callers it will execute dynamic code. This should be conditional on the deployment's opt-in.

[pranaygp]

Blocking: stored code isn't required to be encrypted.

The generic decrypt() returns non-encr data unchanged, so plaintext devl bytes hydrate fine even when the run has a key. I reproduced this: hydrateDynamicWorkflowCode(await dehydrateDynamicWorkflowCode(code, undefined), realKey) === code. It also opens SEALED envelopes, which anyone holding the run's public key can produce by design.

So a hand-built run_created or queue message carrying plaintext code gets executed. The "encrypted storage" framing suggests an integrity property that doesn't exist.

Suggested fix: when the run has a symmetric key (or features.encryption), require the encr format here and reject plaintext and sealed. Please also document that encryption gives confidentiality only: anyone who can obtain the run key can still write valid code, so this narrows the gap but doesn't replace the deployment opt-in.

[pranaygp]

Blocking (docs): these use cases contradict the Security section.

"a customer drags boxes together" and "Customer-defined automations" mean source built from end-user input, and "AI-generated plans" is prompt-injectable model output. Line 212 then says not to pass source from an untrusted user.

Please either drop the customer-authored framing or point it at a real sandbox. In the Security section, state plainly that dynamic source runs with the full privileges of your function: it can read every environment variable, use the network and filesystem, and call any step in the deployment, and steps does not restrict that.

[pranaygp]

Note: this affects static runs too. validateRunExecutionContext runs on every start(), not only dynamic ones. It adds a JSON.stringify per start and throws a plain Error that says "Dynamic step metadata may be too large" even for static runs. Combined with the backend now measuring JSON size rather than CBOR size, a static run whose traceCarrier (baggage/tracestate) is close to 2 KB can start failing where it used to pass. Please scope it to dynamic runs (or keep the old behaviour for static ones), fix the message, and throw a typed WorkflowRuntimeError.

[github-actions]

No backport to stable for 20e8440 (AI decision).

This commit adds an entirely new experimental capability — dynamic workflows started from source strings, with a new experimental_dynamic API surface on start(), new world storage/capability plumbing, a new Postgres migration, a new WORKFLOW_EXPERIMENTAL_DYNAMIC_WORKFLOWS env flag, new docs, and a minor changeset across eight packages. It is feature work by any measure, so it does not belong on the maintenance line. The handful of fix-labelled sub-commits (e.g. world-local dropping the code across status transitions, the module-syntax regex, the web replay guard) all fix defects introduced by this same feature and have nothing to repair on stable.

To override, re-run the Backport to stable workflow manually via workflow_dispatch and paste this commit SHA into the ref input:

20e8440f6ec31dbe3226c9e99b2a8c5d861c975e