Render Workflows vs Vercel Workflows: durable compute vs durable orchestration

Vercel Workflows and Render Workflows both provide durable orchestration with automatic retries, but they start from different premises.

Vercel Workflows makes the orchestration durable inside your application code. It records every step in an event log and replays your workflow function to recover. Each step runs inside a Vercel Function invocation with a duration limit of minutes.

Render Workflows makes the compute durable, with a separate layer that runs your tasks. Each task run gets its own instance, and you set its compute plan (CPU and memory) for each task, up to 8 CPU and 32 GB. A run can last up to 24 hours.

This difference affects:

• How you write workflows
• Where each step runs
• How much CPU, memory, and time each step can use
• How each product bills for usage

The short answer

• Choose Vercel Workflows if you're a TypeScript team already on Vercel, you want durability inside your Next.js codebase, and your workflows chain many short steps that fit within Vercel Function limits.
• Choose Render Workflows if your steps need more CPU, memory, or time than a function allows, such as video processing, large file parsing, or model inference. Render also fits if your agent stack is mostly Python or your backend runs outside Vercel.
• Use both by running the frontend and short orchestration on Vercel and the heavy tasks on Render.

This article compares only the workflow products. For a platform-level comparison, see Render vs. Vercel.

Render Workflows vs Vercel Workflows at a glance

What is Vercel Workflows?

Vercel Workflows runs stateful functions that coordinate multi-step logic over time. It became generally available on April 16, 2026, and is built on the open-source Workflow SDK. You mark an async function with the "use workflow" directive to make it an orchestrator, and you mark the functions it calls with "use step". Vercel runs both kinds of function inside Vercel Functions, uses Vercel Queues to schedule work, and stores run state and event logs in managed storage.

Step functions have full Node.js access and retry automatically. sleep() pauses a run for minutes to months without consuming compute, and hooks and webhooks resume a run when external data arrives. The Vercel Dashboard shows every step, input, output, sleep, and error from each run's event log, and the workflow CLI inspects runs from the terminal. Pluggable storage backends called Worlds let the Workflow SDK run outside Vercel, for example on the self-hosted Postgres World.

What is Render Workflows?

Render Workflows is an end-to-end orchestration and execution engine for long-running, distributed tasks. It became generally available on September 1, 2026. You use the Render SDK for Python or TypeScript to mark functions as tasks, then deploy them as a workflow service from a Git repository. When you trigger a task, Render starts the run in its own isolated instance, retries it on failure, and removes the instance when the run completes.

Each task sets its own retry, timeout, and compute plan, and each execution of a task is a run. Inside a task, ctx.step() runs a plain function or a registered task in the same process, as a sequential step with its own retries. A task can also call other tasks with ctx.run(). Each chained run gets its own instance and returns its result to the parent, and you fan out with asyncio.gather or Promise.all. You can start runs from the SDK, the REST API, the Render CLI, or the Render Dashboard, which shows active and completed runs for each task with logs. Use render workflows dev to run and test a local task server before you deploy.

Where does durability live: in orchestration or in compute?

Vercel Workflows makes the orchestration durable, and Render Workflows makes the compute durable. As a result, a single Render task can be much larger than a Vercel step.

In Vercel Workflows, every step runs inside a Vercel Function invocation. A step on Pro or Enterprise runs for up to 800 seconds, or up to 30 minutes with extended duration, which is in beta. Per the Functions limits, a step can use at most 2 vCPU and 4 GB of memory on Pro and Enterprise, and 1 vCPU and 2 GB on Hobby. The run itself has no duration limit, because the workflow can chain thousands of steps and sleep between them. Vercel Workflows suits work made of many short calls: call an API, save the result, wait, call the next API.

In Render Workflows, every task run is its own instance. You pick the compute plan per task, from the default flex plan (up to 1 CPU and 4 GB of RAM) to 8c-32g (8 CPU and 32 GB of RAM). You set the timeout per task anywhere from 30 seconds to 24 hours.

Consider a pipeline that ingests uploaded videos. For each video, it downloads a 3 GB file, transcodes it to three resolutions, extracts audio, transcribes it with a speech model, and writes the results to Postgres. The transcode step can take 40 minutes and needs more than 4 GB of memory.

On Vercel Workflows, the transcode doesn't fit in one step. You would split the transcode into chunks that each finish under the limit, or have the workflow drive a Vercel Sandbox VM, which offers up to 8 vCPU and 16 GB of memory on Pro and bills separately. Either way, the heavy work moves out of ordinary step code.

On Render Workflows, the transcode is one task on a larger plan:

The parent task runs on the small default plan, and each transcode gets four CPUs and 16 GB of RAM. If a transcode fails, Render retries that run on its own instance.

Choose Vercel Workflows if your steps are short API calls and the long part of the run is waiting. Choose Render Workflows if a single step needs more than 30 minutes or over 4 GB of memory, and you want that step to stay an ordinary function.

Comparison by dimension

Programming model

Vercel Workflows recovers by deterministic replay, so workflow functions must follow determinism rules. They run in a sandbox without Node.js modules, so npm packages that depend on Node.js modules don't work there. Global fetch and setTimeout aren't available, and Date and Math.random return the same values on every replay. You put I/O in step functions, and the workflow function re-runs against the event log to reach its current point.

Render Workflows has no sandbox, so a task is an ordinary function with full access to its language runtime and packages. Render also replays a task after a retry or an infrastructure failure. Each completed ctx.step() returns its saved result instead of running again, so its side effects don't repeat. If a replay doesn't match the saved steps, a determinism check fails the run. Code outside a step runs again on every replay, so make that code safe to repeat, for example by using upserts in database writes.

Choose Vercel Workflows if your team is comfortable separating orchestration code from step code. Choose Render Workflows if you want to turn existing functions into tasks without learning which code can run where.

Languages

Render Workflows has generally available SDKs for Python and TypeScript. Vercel Workflows supports TypeScript and JavaScript across frameworks such as Next.js, Nuxt, SvelteKit, Hono, and Express. Its Python SDK is in beta, requires Python 3.12 or later, and has the same determinism rules. In Python, you call helpers such as workflow.now() and workflow.random() in place of the standard time and random functions.

Choose Vercel Workflows if your codebase is TypeScript and it already runs on Vercel. Choose Render Workflows if your pipelines are in Python, which is common for AI, data, and machine learning work, and you want a stable SDK.

Waiting and human-in-the-loop

Vercel Workflows handles long waits well. sleep('7 days') pauses a run without consuming compute, and hooks resume a run when a person approves a request or an external system calls back. Render Workflows has no pause or sleep primitive yet. A waiting run holds its instance until the run completes or reaches its timeout, which can be at most 24 hours. On the flex plan, Render bills for the CPU and memory a run uses, so a waiting run costs little. To wait for approval on Render, end the run and start a new one when the approval arrives.

Choose Vercel Workflows if your runs wait hours or days for people or webhooks. Choose Render Workflows if your runs are mostly active compute.

Data and networking

Render Workflows task runs can connect to Render Postgres, Render Key Value, and private services in the same region over the private network, with no public internet hop. If the workflow belongs to a network-isolated environment, its runs can't reach other services in that environment over the private network. Vercel Workflows stores its own run state in managed storage, but by default your functions reach a Marketplace database over the public internet. Vercel offers AWS PrivateLink on Pro and Enterprise to connect to resources in your AWS account.

Choose Vercel Workflows if your data is in AWS and you can set up PrivateLink. Choose Render Workflows if your database and services already run on Render.

Developer workflow

Vercel Workflows deploys with your Vercel app, and each run stays on the deployment that started it. Local development uses the Local World and a web UI for inspecting runs. Render Workflows deploys as a separate workflow service from a Git repository, and you declare it in a Blueprint with type: workflow. Compute plans live in task code, so the Blueprint has no plan field. Workflow services aren't included in preview environments. Run render workflows dev to test tasks locally.

Choose Vercel Workflows if you want workflows to ship in the same deployment as your frontend. Choose Render Workflows if you want workflows deployed and scaled separately from your web app.

Pricing model

Vercel Workflows bills several resources, per its pricing page. Workflow Events cost $0.02 per 1,000, Data Written costs $0.50 per GB, and Data Retained costs $0.50 per GB-month. A typical step produces three events. Vercel bills the Functions that run your steps at its standard Functions compute rates, and bills Queues operations separately.

Render Workflows bills compute for each run by the second, per its limits and pricing page. The flex plan bills $0.20 per CPU-hour of CPU time used and $0.05 per GB-hour of RAM, up to $0.40 per hour. Fixed plans bill a flat hourly rate, from $0.40 per hour for 2c-4g to $2.50 per hour for 8c-32g. Task state retention costs $0.25 per GB. Render queues and provisions runs at no additional cost.

Choose Vercel Workflows if you run many small steps that frequently require waiting. Choose Render Workflows if you want one compute meter that tracks how long and how large each task is.

Security and compliance

Both Vercel and Render hold SOC 2 Type 2 reports, and Render holds ISO 27001 certification. Vercel Workflows encrypts step payloads end to end, and only team owners and members with the Workflow Run Data Viewer permission can decrypt run data. Vercel offers a HIPAA business associate agreement (BAA) as a Pro add-on and on Enterprise. Render offers a BAA on Scale and Enterprise plans, but Render Workflows isn't available in HIPAA-enabled workspaces yet.

Choose Vercel Workflows if your workflows process protected health information and Vercel confirms that your BAA covers them. Choose Render Workflows if your workflows don't handle protected health information and your requirements are covered by SOC 2 Type 2 and ISO 27001.

AI and agent workloads

Many agents wait for approvals or callbacks and run heavy compute between them. Vercel Workflows handles the waits, and its agent harnesses make coding agents durable, with Claude Code and Codex (both marked experimental) running only inside Vercel Sandbox. Render Workflows handles the compute. A task can run model inference on 8 CPUs, parse a large document set, or crawl for hours, and it can read and write to Postgres over the private network.

Choose Vercel Workflows if your agents spend most of their time waiting. Choose Render Workflows if your agents spend most of their time computing.

When to choose Vercel Workflows

• Your app is TypeScript and already deploys on Vercel, so workflows ship with your existing deployments.
• Runs wait hours, days, or weeks for sleeps, approvals, or webhooks, and you don't want to pay for compute while they wait.
• Every step finishes in under 30 minutes and fits in 4 GB of memory.
• You want a built-in run dashboard with end-to-end encrypted payloads.
• You want open-source code that can run on other backends through Worlds.
• Your workflows handle protected health information, and your Vercel BAA covers them.

When to choose Render Workflows

• Individual steps are heavy: long-running model calls, video and image processing, large file parsing, or long scrapes.
• A step needs more than 30 minutes of runtime or more than 4 GB of memory, and you don't want to manage a separate VM for it.
• Your pipelines are in Python and you want a generally available SDK.
• You want tasks to be ordinary functions, without a sandbox.
• Your tasks read and write Render Postgres, Render Key Value, or private services over the private network.
• You want one compute meter per run, with per-task plan choices.

How do you use Render Workflows and Vercel Workflows together?

Run the orchestration on Vercel and send the heavy steps to Render. A Vercel workflow can create a webhook, start a Render task that reports to it, and pause without compute until the task finishes:

1. A user action in your Next.js app on Vercel starts a Vercel workflow.
2. The workflow creates a webhook with createWebhook().
3. A step starts a Render task with the Render SDK and passes the webhook URL as an argument.
4. The Render task runs on the compute plan it needs, writes results to Render Postgres, and posts a summary to the webhook URL.
5. The Vercel workflow resumes when the request arrives and continues with notifications or approvals.

Add the callbackUrl parameter to the Render task, and have the task send a POST request to that URL when it finishes. Store RENDER_API_KEY as an environment variable in your Vercel project.

Moving from Vercel Workflows to Render Workflows

The "use workflow" function becomes a parent Render task. Each "use step" function it calls becomes a ctx.step() call inside that parent task. If a step needs its own instance or compute plan, make it a separate Render task that the parent calls with ctx.run().

You can replace sandbox workarounds, such as fetch calls wrapped in steps, with ordinary library calls. Render has no equivalent of sleep() or hooks, so split each long wait into two runs and start the second run from the webhook handler or a cron job. Start with the Render Workflows tutorial or run render workflows init to scaffold a project.

Frequently asked questions