Best durable workflow platforms for AI agents and LLM workloads

There is no single best durable workflow platform for every AI workload. Choose based on where your code runs, how much compute one step needs, how long runs wait, which languages you use, and how the platform bills.

• Choose Render Workflows for Python or TypeScript agents with compute-heavy tasks. Each task gets managed compute with up to 8 CPU, 32 GB of RAM, and 24 hours of runtime, without a worker fleet to operate.
• Choose Temporal for workflows that can run for weeks or months, especially if you need Go, Java, .NET, or durable signals and timers.
• Choose Inngest for event-driven applications that already run on serverless infrastructure and need concurrency, throttling, or debounce controls.
• Choose Trigger.dev for long-running TypeScript tasks on managed compute, especially when runs spend significant time waiting.
• Choose DBOS if you already operate Postgres and want to add durability as a library.
• Choose AWS Lambda durable functions if your application is already on AWS and each compute step fits within Lambda's limits.

The central distinction is who runs your code. Some products make orchestration durable but execute each step on workers or functions that you operate elsewhere. Others manage both orchestration and compute. That difference determines the infrastructure you maintain, the resources available to a single task, and how many services appear on your bill.

Why AI workloads need durable execution

An AI agent run might call a model a dozen times, invoke tools, wait on rate limits, parse a large document, and write results to a database. Any one of those operations can fail. If the process crashes after the ninth model call, restarting from the beginning repeats completed work and can pay the model provider twice.

A durable workflow records progress as the run advances. After a crash or infrastructure failure, it reuses the results of completed steps and resumes the remaining work. This is particularly useful for AI workloads because they combine two very different kinds of steps:

• Compute-heavy steps, such as local inference, document parsing, media processing, and long-running scrapes.
• Wait-heavy steps, such as model API calls, human approvals, rate-limit backoffs, and external callbacks.

Products optimize for different sides of that split. A platform designed for cheap, multi-day waits is not necessarily a good place to run a 40-minute parser that needs 16 GB of RAM. A platform designed for active compute might not be the cheapest place to hold thousands of approval requests open for a week.

Durable execution also does not guarantee that every side effect happens exactly once. If a step sends an email and crashes before recording its result, the platform can retry it. Use idempotency keys, unique database constraints, or upserts for effects that must not be duplicated.

How to choose a durable workflow platform

Compare platforms on the following dimensions before comparing feature counts.

Where does your code run?

Managed orchestration does not always include managed compute. Temporal Cloud, Inngest, Hatchet Cloud, and Restate Cloud can operate the durable control plane while your workers or services run elsewhere. You still size, deploy, patch, and pay for that compute.

Render Workflows and Trigger.dev run task code on managed instances. Lambda durable functions, Cloudflare Workflows, and Vercel Workflows run steps in their respective function runtimes. DBOS runs as a library in your application.

How much compute can one step use?

Look at the limit for one step, not the maximum lifetime of the overall workflow. A workflow can remain open for a year while each individual invocation is limited to a few minutes.

For API orchestration, small function instances are often enough. For model inference, video processing, browser automation, large file parsing, or a long scrape, compare CPU, memory, local disk, and wall-clock limits.

Can a run wait without holding compute?

Durable timers and signals let a run sleep or wait for an external event without keeping a process alive. They are important for approval flows, callbacks, and workflows that span days or months.

Temporal, Inngest, Trigger.dev, DBOS, Lambda durable functions, Cloudflare Workflows, Vercel Workflows, Hatchet, and Restate all provide mechanisms for durable waits. Render Workflows does not yet have a pause primitive. A waiting Render task keeps its instance until it completes or reaches its timeout.

How does recovery work?

Many platforms recover by replaying workflow code and returning saved results for completed steps. Code between those steps must make the same decisions during replay. Put non-deterministic operations, including LLM calls, current time, random values, and network requests, inside durable steps.

Other products retry a task from the beginning while allowing completed child tasks to return cached results. Read the recovery model carefully: "durable" does not always mean recovery resumes at the exact line that failed.

Does it support your language natively?

Python is common in AI, data, and machine-learning systems, but several workflow products are TypeScript-first. Distinguish a native, generally available Python SDK from a beta SDK or the ability to launch a Python script from a TypeScript task.

What does the platform meter?

Common billing dimensions include:

• Workflow starts, steps, actions, or events
• Compute duration and machine size
• Stored workflow state and retention
• Seats, environments, or concurrency
• The separate infrastructure that runs your workers

Per-step pricing can matter for agents with long tool loops. Compute pricing matters more when a small number of steps use large machines for a long time. Include all providers when estimating the total cost.

Durable workflow platforms compared

Among the products that also operate the task compute, Render Workflows and Trigger.dev expose multi-GB machine sizes intended for long-running application code. Lambda, Cloudflare, and Vercel also manage compute, but each step runs within its function runtime and resource limits.

Best durable workflow platform by use case

• Best for compute-heavy AI tasks in Python: Render Workflows. A task can use up to 32 GB of RAM for up to 24 hours, and Python is a first-class SDK.
• Best for long-lived workflows and polyglot teams: Temporal. It supports the broadest language set here and has mature timers, signals, and operational controls.
• Best for event-driven serverless applications: Inngest. It adds durable steps, event triggers, concurrency, throttling, and debounce to functions you already host.
• Best for TypeScript tasks with managed compute and long waits: Trigger.dev. It checkpoints waits and subtasks so they do not consume compute.
• Best for Postgres-backed applications that want a library: DBOS. Workflow state lives in Postgres, and you do not need a separate orchestration server.
• Best for AWS-native applications: Lambda durable functions. They use Lambda's existing runtime, IAM, and service integrations.
• Best for lightweight workflows at the edge: Cloudflare Workflows. They pair durable steps and year-long sleeps with the Workers platform.
• Best for Next.js applications already on Vercel: Vercel Workflows. Workflows deploy with the application and can pause on hooks and webhooks.
• Best open-source task queue with durable workflows: Hatchet. It offers Python, TypeScript, Go, and Ruby SDKs with a self-hosted control plane.
• Best for low-latency durable handlers in many languages: Restate. It combines durable execution with keyed state, durable RPC, timers, and signals.
• Best when the agent also needs managed Postgres and web hosting: Render Workflows. Tasks can reach the rest of a Render environment over the private network.

Platform profiles

Temporal

Temporal is an open-source durable execution platform. Workflow code calls activities, and the Temporal Service records events so another worker can replay the workflow and continue after a failure. Durable timers and signals allow a workflow to wait for months without holding a worker.

Temporal Cloud operates the orchestration layer, but traditionally your team runs the workers that execute workflow and activity code. Serverless Workers can start workers on AWS Lambda, Amazon Bedrock AgentCore Runtime, and Google Cloud Run, but the feature is in public preview and inherits each provider's limits.

Temporal is a strong fit for long-lived processes, polyglot organizations, and teams that need mature versioning and operational controls. The tradeoff is additional complexity. Workflow code must be deterministic, and large LLM payloads can run into Temporal's 2 MB payload and workflow-history limits. Temporal Cloud bills actions and storage, while worker compute is a separate cost.

Inngest

Inngest is an event-driven durable execution platform for TypeScript, Python, and Go. You divide a function into durable operations with step.run(). Inngest stores each completed step and replays the function to recover.

Your code runs on servers or serverless functions you host, or on long-running workers connected through Inngest Connect. This makes Inngest a natural addition to an existing serverless application, but the available CPU, memory, and duration come from that host. Inngest caps a step at two hours even when the host allows more.

Inngest includes per-customer concurrency, throttling, debounce, durable sleeps, and event waits. Its step.ai.infer() API can make a model request outside your function's compute window. Inngest bills a function run and each step as executions, and you pay your hosting provider separately for compute.

Trigger.dev

Trigger.dev is an open-source platform for background jobs and AI workflows. Trigger.dev Cloud builds TypeScript tasks and runs them on managed machines ranging up to 8 vCPU and 16 GB of RAM. Tasks have no fixed maximum duration.

Trigger.dev checkpoints a wait.for() call longer than five seconds, and it checkpoints a parent while that parent waits for subtasks. Those waits do not consume compute or concurrency. This makes Trigger.dev well suited to agents that alternate between active work and long idle periods.

Trigger.dev is TypeScript-first. It can package and run Python scripts through its Python build extension, but Python is not the workflow definition language. Cloud pricing combines machine time by the second with a $0.25 fee per 10,000 run invocations. Preview branches and a HIPAA BAA add-on are available.

DBOS

DBOS is an open-source durable execution library that uses Postgres as the system of record. Annotated workflows call steps, and DBOS records their results in Postgres. If an application process stops, it resumes from the last completed step when it comes back.

DBOS supports Python, TypeScript, Go, and Java. DBOS.sleep() records a wake-up time in the database, so a workflow can sleep for days or months across restarts. Transactions can commit exactly once when they run through DBOS.

DBOS is a good fit for teams that already operate Postgres and want durability inside an existing application. You still deploy and scale the application servers and database. DBOS Conductor adds production recovery, workflow management, observability, retention, and autoscaling controls through a separate enterprise package.

AWS Lambda durable functions

AWS Lambda durable functions add checkpointed steps, retries, and waits to Lambda. A durable execution can last up to one year, and waits suspend the function without compute charges. Recovery replays the function from the start and skips operations whose results are already stored.

Each standard Lambda invocation still has Lambda's 15-minute timeout and up to 10 GB of memory. A durable execution can persist up to 100 MB of state, so large prompts, documents, and model responses should live in S3 or another external store.

Lambda durable functions fit applications that already use AWS and whose individual steps fit Lambda. Billing includes normal Lambda requests and active duration plus durable operations and persisted data. Code outside durable steps must remain deterministic.

Cloudflare Workflows

Cloudflare Workflows adds durable steps, retries, sleeps, and event waits to Cloudflare Workers. A step can have unlimited wall-clock time while it waits on network I/O, but active CPU time is capped at five minutes on the paid plan. A workflow can sleep for up to 365 days without consuming a concurrency slot.

Cloudflare prices Workflows on requests, CPU milliseconds, steps, and stored state. The paid plan includes allowances for each dimension, and idle time does not consume CPU.

Cloudflare Workflows is strongest for lightweight orchestration near users and data already on Cloudflare. It is not designed to run memory-heavy inference or document processing inside a step. A non-streamed step result is capped at 1 MiB, so large artifacts should go to R2 or another object store.

Vercel Workflows

Vercel Workflows uses "use workflow" and "use step" directives to add durable execution to a TypeScript application. The workflow function replays against an event log, while step functions run with full Node.js access in Vercel Functions. sleep(), hooks, and webhooks pause a workflow without holding compute.

On Pro and Enterprise, an ordinary step gets up to 2 vCPU, 4 GB of memory, and 800 seconds. Extended 30-minute steps are in beta. Workflow orchestration runs in a deterministic sandbox, and the Python SDK is also in beta.

Vercel Workflows is a good choice for TypeScript and Next.js applications already deployed on Vercel, especially when workflows mostly call APIs and wait. For a detailed comparison, see Render Workflows vs. Vercel Workflows.

Hatchet

Hatchet is an MIT-licensed task queue and durable workflow engine with SDKs for Python, TypeScript, Go, and Ruby. Hatchet Cloud operates the control plane, while workers that execute tasks run on your infrastructure. You can also self-host the control plane with Postgres and, for larger deployments, RabbitMQ.

Hatchet provides retries, schedules, concurrency controls, rate limits, durable sleep, observability, and workflow replay. It is a strong fit for teams that want an open-source worker model and more task-queue controls than a basic queue offers.

Hatchet Cloud includes 1 million runs and 1 million events each month, then charges $30 per million runs and $5 per million events. Your worker compute is a separate infrastructure cost and operational responsibility.

Restate

Restate is a durable execution runtime with built-in keyed state, durable RPC, queues, timers, and signals. It journals operations and their results, then replays a handler after failure without repeating completed operations.

Restate supports TypeScript, Python, Java, Kotlin, Go, Rust, and Ruby. Application services run on infrastructure you choose, including containers, Kubernetes, and serverless functions. Restate Cloud operates the coordination environment; Restate also offers bring-your-own-cloud and self-hosted options.

Restate is a good fit for teams that want durable execution in low-latency application handlers as well as background workflows. Durable timers and signals work well for human-in-the-loop agents. The tradeoff is that Restate Cloud does not run your application services, so you deploy, scale, and pay for their compute separately.

How Render Workflows works

Render Workflows runs the orchestration layer and the compute that executes each task. You define a task as a Python or TypeScript function and deploy a workflow service from Git. When a task starts, Render creates an isolated instance for that run, then removes it when the run finishes. There are no idle worker processes between runs.

Each task can set its own compute plan, timeout, and retry policy. Plans range from the default flex plan, with up to 1 CPU and 4 GB of RAM, to 8c-32g, with 8 CPU and 32 GB of RAM. The default timeout is two hours, and a task can extend it to 24 hours.

A task can call another task with ctx.run(). The child gets a separate instance and retries independently, so different parts of a workflow can use different compute plans. Within a task, ctx.step() saves a function's result. If the task retries, completed steps return their stored results instead of calling the model or external API again.

The following workflow runs each document summary in parallel. Every summarize_document run gets its own managed instance:

Task runs can connect to Render Postgres, Render Key Value, web services, and private services in the same region over the private network. That makes Render Workflows useful when the workflow is one part of a larger application stack rather than a standalone orchestrator.

Render bills task compute by the second. The flex plan bills actual usage at $0.20 per CPU-hour and $0.05 per GB-hour of RAM. Fixed plans range from $0.40 per hour for 2c-4g to $2.50 per hour for 8c-32g. Retaining task inputs and return values for 30 days costs $0.25 per GB. There is no separate per-step, per-run, or per-seat fee.

When not to choose Render Workflows

Evaluate another platform when:

• A run must wait for days or months. Render Workflows has no durable pause or sleep primitive. A waiting task holds its instance and cannot run longer than 24 hours. On Render, save the state to Postgres, end the task, and start a new task when the approval or callback arrives.
• You use Go, Java, .NET, Rust, or Ruby. Render Workflows currently supports only Python and TypeScript.
• You need built-in per-customer throttling or debounce. Inngest and Hatchet provide more granular flow-control primitives.
• You need workflow services in preview environments. Render does not yet create workflow services in preview environments or Blueprint replicas.
• You process protected health information. Render Workflows is not yet available in HIPAA-enabled workspaces.
• You need native schedules. Trigger a workflow from a Render cron job instead.
• You need to pass large payloads between tasks. Task arguments are capped at 4 MB. Store large files and model artifacts in object storage and pass references.
• You require a free allowance. Render Workflows bills from the first run.
• You already operate a workflow platform that meets your needs. Migrating orchestration systems can cost more than the infrastructure it removes.

Frequently asked questions