Vercel Workflow SDK: durable TypeScript functions with a local observability UI

What the Workflow SDK makes durable, and for whom

A TypeScript function that calls an LLM, waits on a webhook, or walks a user through a multi-day onboarding sequence has a problem that ordinary serverless code does not solve: the process can die between steps, and nothing remembers where it was. The Workflow SDK addresses exactly that. The README states that it "makes TypeScript and JavaScript functions durable", persisting workflow progress, retrying failed steps, and providing built-in observability. Workflows can suspend without using compute while they wait.

The audience is narrower than "anyone with a long-running job". This is a TypeScript-first library, distributed as the workflow npm package, and it is built by Vercel with a Next.js integration shown in the README. If your services are Go, Python or Java, the SDK's central abstraction (a workflow defined as a TypeScript function, started with start from workflow/api) does not map onto your code without a rewrite. The fit is teams already writing server-side TypeScript who want durable execution without standing up a separate orchestration service.

How workflows, steps and Worlds fit together

The mechanism visible in the README is a split between the workflow function and the runtime that executes it. You write a workflow in TypeScript and start it from server-side code with start from workflow/api, passing the workflow function and its arguments. The runtime persists progress as the workflow advances, so a workflow that suspends while waiting does not hold compute. Failed steps are retried by the runtime rather than by retry code you write.

The deployment side is abstracted behind a concept the project calls a World. Local development uses "the bundled backend with no configuration". Deploying to Vercel gives managed storage, queuing, scaling and observability. Self-hosting means using the Postgres backend or implementing a custom World. The Worlds page lists maintainer-curated third-party Worlds, including self-hosted and managed options, and submissions go through worlds-manifest.json at the repository root.

That World boundary is the interesting design decision. It means the storage and queue layer is swappable, but it also means the operational behaviour you get (retry semantics under load, how far back you can inspect history) depends on which World you pick, not on the SDK alone. The README points to the deploying docs rather than describing those semantics itself.

Installing the SDK and starting a first workflow

Installation is a single npm package added to an existing project. The README gives this command:

npm install workflow

After that, you configure the integration for your framework. The README's example is Next.js, in next.config.ts, wrapping the config with withWorkflow:

// next.config.ts
import { withWorkflow } from 'workflow/next';

export default withWorkflow({});

The README directs readers to the getting-started guides on workflow-sdk.dev to choose a framework, so if you are not on Next.js, that page is where the per-framework configuration lives.

Starting a workflow happens from an API route, a Server Action, or other server-side code. The README's example imports start from workflow/api and passes a workflow function plus its arguments:

import { start } from 'workflow/api';
import { onboardUser } from './workflows/onboard-user';

await start(onboardUser, ['[email protected]']);

To observe what happened, run your app and then open the local observability UI from a second terminal:

npx workflow web

The README notes that the workflow package ships its full documentation inside node_modules/workflow/docs, which is aimed at coding agents reading version-matched guides locally. That is a real convenience: the docs you read match the version you installed, rather than whatever the site currently shows.

Where the SDK is the wrong tool

The clearest limitation is portability of the runtime. Local development works with no configuration, but the README's production story is either Vercel for managed storage, queuing, scaling and observability, or self-hosting through the Postgres backend or a custom World. If your constraint is running on infrastructure you already operate without adopting a Vercel-shaped deployment model, you are on the self-hosted path, and the README does not document what that path costs you in configuration or what guarantees the Postgres backend provides.

There is also a versioning cost that the repository layout makes visible. The workspace package.json pins Node to ^22.0.0 || ^24.0.0 and uses pnpm 11.24.0 with Turborepo. Those are workspace constraints, not necessarily constraints on consumers of the published package, but they tell you the project's own toolchain moves quickly. Releases are frequent and granular: [email protected], 4.8.7 and 4.8.8 all landed on 2026-09-09. A library publishing three patch releases in a day is a library you should pin.

One thing the README does not cover at all is rollback. There is no documented procedure for reverting a deployed workflow definition, and no statement about what happens to in-flight workflows whose code changes underneath them. For a system whose whole value proposition is durable state, that silence matters more than it would elsewhere.

How it differs from Temporal and the other durable execution engines

The obvious comparison is Temporal, which also provides durable execution with retries and persisted state. The difference in approach is where the code and the runtime live. Temporal asks you to run a cluster (or use Temporal Cloud) and write workflows against its SDK and worker model; the engine is the product, and it is language-agnostic. The Workflow SDK inverts that: the workflow is an ordinary TypeScript function in your existing app, started from an API route or Server Action, and the engine is a backend you select through a World. There is no separate worker process to deploy in the README's local and Vercel paths.

That inversion is what makes the SDK pleasant for a Next.js app and awkward for anything else. If you already run Temporal, or you need workflows written in a language Temporal supports and TypeScript does not cover, the Workflow SDK is not a drop-in replacement; it is a different architecture with a different operational surface. If your workflows are TypeScript and you would rather not operate a cluster, the trade is real: you get less control over the execution substrate in exchange for not running one.

Maintenance, licence and upgrade cost

The repository is not archived, and the last push was on 2026-09-10. Release cadence is high and the changelog tooling is standard for a Vercel monorepo: Changesets with @changesets/cli, a changeset script, ci:version running changeset version, and ci:publish running pnpm build followed by changeset publish. There is also a release:notes script. Practically, that means upgrades arrive as small, frequent version bumps rather than large migrations, and you should expect to read the changelog between minor versions.

The licence is Apache-2.0, declared in both the repository's package.json and the Cargo workspace manifest, and the README links to LICENSE.md. Apache-2.0 permits commercial use and modification and includes a patent grant, but it also carries notice and attribution obligations, and it is not a copyleft licence, so it does not force you to publish your own workflow code. The README does not state any additional terms for the hosted Vercel backend, which is a separate service from the open source package. That distinction is worth checking before you assume the licence covers the managed path; the README does not settle it, and this is not legal advice.

Security reports go through [email protected] rather than public issues, and the README mentions an Open Source Software Bug Bounty program. If your organisation requires a documented disclosure channel before adopting a dependency, that requirement is met.

Editorial conclusion

Adopt it if your app is TypeScript, your long-running work is already shaped like functions and steps, and you accept Vercel as the managed path or the Postgres backend as the self-hosted one. Do not adopt it if you need a language-agnostic engine, an air-gapped deployment with a documented upgrade path, or a rollback procedure the README spells out; none of those are covered in the README. Before committing, verify three things: that the framework you use has a getting-started guide, that the World you intend to deploy against is listed on the Worlds page or in worlds-manifest.json, and that the Node version your CI runs satisfies the ^22.0.0 || ^24.0.0 range in the workspace package.json.

Frequently asked questions

Official sources

1. License: Apache-2.0
2. Project website
3. README
4. Releases
5. vercel/workflow on GitHub