Vercel's Workflow SDK 5 adds per-run encryption and regional execution for durable JavaScript workflows

Vercel has released version 5 of its Workflow SDK, the runtime that keeps ordinary async JavaScript functions running through crashes, deployments and long waits. The update concentrates on three areas the company says production customers now demand: payload security, regional execution and performance for agent workloads.

According to Vercel's announcement, the SDK has processed more than 4 billion steps across 700 million runs since launching. Usage has settled into two patterns: traditional automation such as order processing, subscription management and data pipelines, and AI agents and harnesses, which are long-running and expensive enough to require durability.

Payloads are encrypted end to end

The workflow event log records step arguments and return values so a run can recover after a crash or deployment, but that data can include customer information, model context, credentials and tool-call results. In v5, the SDK encrypts every payload with AES-256-GCM before it leaves the developer's code, using a unique key for each run. Vercel says that with encryption enabled its own backend, like any Workflow SDK backend, only sees and stores ciphertext; plaintext is decrypted inside the customer's deployment or in authorized observability tools.

On Vercel's platform this needs no setup and no code changes. Each run's key is derived from a key scoped to the deployment that created it, so a run can only decrypt its own data. Names, timings and statuses remain visible for observability, and payloads can be decrypted through the dashboard or CLI. Decryption happens in the browser or terminal, follows the same permissions as the project's environment variables, and every request is recorded in the team's audit log.

Because encryption lives in the SDK rather than the platform, self-hosted Worlds can use it too. A custom World enables the feature by implementing getEncryptionKeyForRun(), returning the same 32-byte key for a given run on every call so replays can still decrypt. Cross-run writes are also covered: when code resumes another run's hook, starts a run in another deployment or writes to a forwarded stream, the payload is encrypted to the target run's public key. A retention option, experimental_retention: 0, deletes inputs, outputs and stream contents as soon as a run completes or fails, while keeping run metadata visible.

A redesigned trace viewer and run attributes

The v5 trace viewer adds span search, zoom, a minimap and local inspection during development. Run attributes are new in this release, letting developers attach searchable context such as an order ID to a run and then find runs by that value. Vercel notes that attributes are stored in plaintext and should not contain secrets.

Runs execute in every region

In SDK 4, every run lived in Vercel's iad1 region regardless of where the project was deployed, so steps running anywhere else made cross-region requests to record their progress. For v5, Vercel deployed Workflow infrastructure to every Vercel Function region. Each run now has a home region that serves its state, queue dispatch and streams without cross-region round trips on the hot path.

By default a run starts in the region of the function that starts it, so a multi-region deployment keeps each run close to the user who triggered it. A region option on start() can place a run elsewhere, for example next to the database it accesses or to keep a customer's data in a specific jurisdiction. Existing v4 runs stay in iad1, and the region option governs where a run's data lives while steps execute wherever the app is deployed.

Reliability and agent performance

Vercel says regional isolation also improves reliability: a disruption in one region need not stop new runs in healthy regions, and projects with Vercel Function failover configured can execute steps in a fallback region while state remains pinned to the run's original home region rather than migrating. The company also says it fixed dozens of rare bugs and race conditions in the runtime, found through anonymized telemetry and work with customers, and that it now sees almost no runs failing or stalling because of a platform or runtime bug.

On performance, Vercel acknowledges that v4 routed every step invocation through two queue hops, one to start the step and one to continue the workflow. That is acceptable for slow background automation but adds latency to the AI workloads developers are building now, where agent loops and harnesses can contain thousands of sequential events. The v5 performance work is aimed squarely at these workloads.

Why it matters

Durable execution has largely been the territory of dedicated orchestration engines, and Vercel's pitch is that plain async JavaScript with a "use workflow" directive is enough to get it. The security change is the most consequential part of this release: event logs that persist step inputs and outputs are a genuine liability when payloads hold credentials or customer data, and encrypting them per run, with the platform storing only ciphertext, is a strong default for a hosted service. Regional execution addresses both latency and data-residency obligations, which matter for regulated workloads. And with agents now a major driver of usage, v5 positions Workflow as infrastructure for long-running AI systems rather than just background jobs.