Render Workflows vs Temporal: managed compute vs your own workers

Temporal and Render Workflows both orchestrate multi-step work with automatic retries, but they split the work differently.

Temporal makes the orchestration durable. The Temporal Service records each workflow step in an event history and replays your workflow code to resume after a failure. Your code runs on workers in your own infrastructure: servers, Kubernetes, or serverless platforms like AWS Lambda and Cloud Run (in preview).

Render Workflows also runs the compute, so you have no worker infrastructure to provision, scale, or patch. Each task run gets its own instance, and you choose a compute plan per task, up to 8 CPU and 32 GB RAM.

This difference affects:

• How you write workflows
• Who runs and scales the machines that execute each step
• How long a workflow can run and wait
• How each product bills for usage

The short answer

• Choose Temporal if your workflows run for days or months. Temporal also fits if you need an SDK in Go, Java, .NET, Ruby, PHP, or Rust, you already run a worker fleet, or you want an open-source server that you can self-host.
• Choose Render Workflows if you want the platform to provision compute for each task, with no worker fleet to size, scale, or patch. Render also fits if your steps need large, varied compute plans, your pipelines are in Python or TypeScript, and you also need managed Postgres and web service hosting for your application.
• Use both by running long-lived orchestration on Temporal and sending the heavy tasks to Render.

Render Workflows vs Temporal at a glance

What is Temporal?

Temporal is an open-source durable execution platform. You write a workflow as ordinary code that calls activities, which are the functions that do I/O, such as API calls, database writes, and file processing. The Temporal Service stores each workflow's event history, and workers that you run poll task queues for work. If a worker crashes, another worker replays the workflow's event history to rebuild its state and continues from the last recorded step.

Activities retry automatically with configurable retry policies and timeouts. Durable timers pause a workflow for minutes to months, signals and updates send data into a running workflow, and queries read its state. Schedules start workflows on a calendar or interval. You can self-host the MIT-licensed server, or use Temporal Cloud, which runs the Temporal Service for you. Temporal Cloud doesn't run your workers. Serverless Workers, which let Temporal Cloud start and scale your workers on AWS Lambda or Google Cloud Run based on task volume, entered public preview for Lambda in August 2026 and for Cloud Run in October 2026.

What is Render Workflows?

Render Workflows is an end-to-end orchestration and execution engine for long-running, distributed tasks. 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.

Who runs the compute: you or the platform?

On Render you size each task in code, and on Temporal you size a worker fleet.

In Temporal, an activity runs on whichever worker polls its task queue first. An activity has no fixed duration limit. You set a start-to-close timeout, and for long activities you set a heartbeat timeout and call activity.heartbeat() so Temporal detects a crashed worker before the full timeout passes. The CPU and memory an activity gets depend on the machine its worker runs on. To give heavy activities more resources, you route them to a separate task queue served by larger workers, and you scale those workers for peak load. Temporal Cloud's Serverless Workers (in preview) remove the fleet. On AWS Lambda, each activity must finish within Lambda's 15-minute invocation limit.

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, and the default is 2 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 Temporal, the transcode is an activity, so you need workers with ffmpeg installed and enough memory for three parallel transcodes per video. You run a dedicated transcode task queue on large machines, heartbeat from inside the transcode loop, and add autoscaling so that a burst of uploads doesn't queue behind a fixed number of workers. Between bursts, you pay for the large workers unless you scale them down.

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. When no videos arrive, no instances run.

Choose Temporal if you already run infrastructure for workers and want full control over the machines. Choose Render Workflows if you want each task to declare the compute it needs, and you don't want to operate a worker fleet.

Comparison by dimension

Programming model

Temporal recovers a workflow by replaying its code against the event history, so workflow code must be deterministic. Every replay must make the same calls in the same order, so workflow code can't read the system clock or generate random values directly. Temporal's docs list the full set of deterministic constraints. The Python SDK runs workflow code in a sandbox that blocks known non-deterministic calls, and the TypeScript SDK runs workflow code in a deterministic sandbox where Date and Math.random return the same values on every replay. You put all I/O in activities. When you change workflow code while runs are in progress, you use patching or worker versioning so that old runs still replay correctly.

Render Workflows has no sandbox, so a task is an ordinary function with full access to its language runtime and packages. Inside a task, ctx.step() runs a plain function or a registered task as a step. Steps run one after another, inline in the same process as their task. Each step has its own retry settings, and Render saves its result once it completes. If the task re-executes, whether because of a retry or an infrastructure failure, completed steps return their saved results instead of running again. Render also checks each replay for determinism. If the replay doesn't match the original run, such as steps running in a different order, the replay fails instead of mixing old and new results.

Code outside of steps still reruns on every retry, so keep it safe to repeat, for example by using upserts in database writes. To run work in parallel on separate instances, chain tasks with ctx.run() instead. When a chained run fails, Render retries only that run.

Choose Temporal if you want an SDK that sandboxes workflow code, and your team is comfortable separating workflow code from activity code and managing versions of in-flight workflows. Choose Render Workflows if you want to turn existing functions into tasks and steps without learning which code can run where.

Languages

Temporal has official SDKs for Go, Java, Python, TypeScript, .NET, Ruby, PHP, and Rust, and a workflow in one language can call activities written in another. Render Workflows has generally available SDKs for Python and TypeScript.

Choose Temporal if your services are written in Go, Java, or .NET, or a single workflow spans several languages. Choose Render Workflows if your pipelines are in Python or TypeScript, which is common for AI, data, and machine learning work.

Waiting and human-in-the-loop

Temporal is designed for long waits. A durable timer (sleep() in most SDKs) can last months, and signals and updates resume a workflow when a person approves a request or an external system calls back. A waiting workflow doesn't hold a worker, and long-running workflows use Continue-As-New to start a fresh event history before they reach the history limit (51,200 events or 50 MB).

Render Workflows doesn't offer a durable pause or sleep yet. A waiting run holds its instance until the run completes or times out. The default timeout is 2 hours, and you can raise it to 24 hours per task. On the default flex plan, Render bills for the CPU and memory a run actually uses, so a waiting run costs little. Render bills runs on fixed compute plans at the full rate while they wait. To wait for approval on Render, save the run's state to Postgres, end the run, and start a new run when the approval arrives. The article on pausing an agent mid-run for approval covers this pattern.

Choose Temporal if your runs wait days or months for people or webhooks. Choose Render Workflows if each wait fits within the 24-hour task timeout, or you can split a longer wait into two runs.

Data and networking

Render Workflows task runs can connect to Render Postgres, Render Key Value, and private services in the same workspace and 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. Temporal workers run in your own network, so they reach your databases and internal services the same way your other services do. Workers connect to Temporal Cloud over the public internet or privately over AWS PrivateLink or GCP Private Service Connect, and authenticate with mTLS or API keys either way.

Choose Temporal if your task code and compute must run in your own cloud account. Temporal Cloud still stores workflow state, so encrypt payloads client-side if that data must stay private too. Choose Render Workflows if you also need managed Postgres and web service hosting for your application.

Developer workflow

With Temporal, you build, deploy, and scale workers like any other service, and you connect them to a Temporal Service. Locally, temporal server start-dev runs a development server with a web UI. Worker Versioning and the Temporal Worker Controller for Kubernetes help you roll out new workflow code without breaking in-progress 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 yet included in preview environments. Run render workflows dev to test tasks locally.

Choose Temporal if you have a platform team that already deploys and scales services on your own infrastructure. Choose Render Workflows if you want a Git push to deploy tasks with no workers to manage.

Pricing model

Temporal Cloud bills Actions and storage, per its pricing page. Actions start at $50 per million, with volume discounts. Starting a workflow, starting or retrying an activity, starting a timer, sending a signal, and receiving a query each count as an Action. Active storage for open workflows costs $0.042 per GB-hour, and retained storage for closed workflows costs $0.00105 per GB-hour. The Pay-As-You-Go plan has no monthly minimum, and it adds Developer support at 10% of usage. You also run your own workers and pay your cloud provider for them. Workers on reserved machines cost money even when they're idle. Serverless Workers on Lambda or Cloud Run, currently in preview, can scale to zero.

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 used, 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. Compute and task state are the only workflow-specific charges. Public internet traffic from your runs counts toward your workspace's outbound bandwidth.

Choose Temporal if you already run workers on reserved capacity with steady load, or if you want to manage worker scaling yourself. Choose Render Workflows if your load is bursty and you want one compute meter that tracks how long and how large each task is.

Security and compliance

Both Temporal and Render hold SOC 2 Type 2 reports, and Render holds ISO 27001 certification. Temporal's SDKs support an optional data converter that encrypts payloads before they leave your workers, so Temporal Cloud can't read your workflow data. Temporal states that Temporal Cloud is HIPAA compliant. Render offers a business associate agreement (BAA) on Scale and Enterprise plans, but Render Workflows isn't available in HIPAA-enabled workspaces yet.

Choose Temporal if your workflows process protected health information and your Temporal agreement covers them. Choose Render Workflows if your processes 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. Temporal handles the waits and the long-lived agent loop, and it integrates with agent frameworks such as the OpenAI Agents SDK. 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 Temporal if your agents run for weeks or months. Choose Render Workflows if your agents need managed heterogenous compute.

When to choose Temporal

• Workflows run for days, weeks, or months, and wait on timers, signals, or approvals.
• Your services are in Go, Java, .NET, Ruby, PHP, or Rust, or one workflow spans several languages.
• You already deploy and scale services on your own infrastructure, and you want workers next to your data.
• You want an open-source server that you can self-host.
• You need built-in Schedules, queries, and updates on running workflows.
• Your workflows handle protected health information, and your Temporal agreement 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.
• You don't want to size, scale, or patch a worker fleet.
• Different tasks need different CPU and memory, and you want each task to declare its plan in code.
• Your tasks read and write Postgres or a Redis-compatible key-value store, or need private networking between services.
• You want one compute meter per run, with no cost for idle workers.

How do you use Render Workflows and Temporal together?

Run the long-lived orchestration on Temporal and send the heavy steps to Render. A Temporal activity can start a Render task and wait for it to finish, and the workflow can then wait days for an approval without using any worker compute:

1. Your app starts a Temporal workflow when a user uploads a video.
2. The workflow runs an activity that starts a Render task with the Render SDK. The activity heartbeats while it waits, so Temporal can retry it if the worker crashes.
3. The Render task runs on the compute plan it needs and writes its output to Render Postgres.
4. The activity returns a reference to that output, such as a row ID, to the workflow.
5. The workflow waits for an approval signal, then continues with notifications or publishing.

Render already retries the task run, so the Temporal retry policy only needs to cover the activity itself, such as a worker crashing while it waits for the run to finish. The activity passes the workflow run ID as the idempotency key, so a retried activity reuses the run started by the first attempt. Render honors the same key for 24 hours. Without a heartbeat, Temporal detects a crashed worker only when the 3-hour start-to-close timeout expires, so in production, heartbeat from a background loop while the activity waits and set a heartbeat_timeout. Store RENDER_API_KEY as an environment variable on your Temporal workers.

Your Temporal workers can also run on Render as background workers, connected to Temporal Cloud or to a self-hosted Temporal cluster. Render provides a Blueprint for a Temporal cluster with Postgres and Elasticsearch.

Moving from Temporal to Render Workflows

The workflow becomes a parent Render task, and each activity becomes a separate task that the parent calls with ctx.run(). Each of those runs gets its own instance and uses the compute plan and retry policy defined on its task. Child workflows also become tasks that the parent calls with ctx.run(). Small activities that don't need their own instance can become ctx.step() calls inside the parent task. If the parent retries, completed steps return their saved results instead of running again.

You can remove sandbox workarounds in workflow code, such as workflow.now() and passed-through imports, because Render doesn't sandbox task code. Keep your steps in the same order on every run, because Render fails a replay that doesn't match the original run. Render has no equivalent of durable timers or signals, so split each long wait into two runs: end the first run, then start the second with the Render SDK from whatever receives the event (such as a webhook endpoint on your web service) or from a cron job. Replace Temporal Schedules with Render cron jobs, and shut down the worker fleet once its task queues are empty. Start with the Render Workflows tutorial or run render workflows init to scaffold a project.

Frequently asked questions