Intro to Render Workflows

Orchestrate chains of distributed, long-running computation.

Render Workflows is an end-to-end orchestration and execution engine for distributed, long-running computation.

Define units of work as standard functions with Render's lightweight SDK, then run them across hundreds of concurrent instances.

Use workflows to orchestrate AI agents, background jobs, data pipelines, and more:

run_agent()30s

gather_context()

execute_skills()

compose_response()

fetch_docs()

search_web()

Render bills you for compute usage (prorated by the second) and for temporary retention of your run arguments and return values. Queuing and provisioning are provided at no additional cost.

At a glance

You define tasks and flows as standard TypeScript or Python functions and register them with Render.
Trigger runs from anywhere: web apps, agents, CI/CD, etc.
- A task can chain runs of other tasks (or itself!) as illustrated above.
Render automatically spins up a separate instance for each run and deprovisions instances as runs complete.

Create your first workflow

Core features

Tasks and flows as functions

Define tasks and flows with the Render SDK. Chain runs by invoking one task from another.
Managed orchestration

Render handles run queuing, spin-up, and deprovisioning, all at no additional cost.
Long-running execution

Runs can execute for up to 24 hours. Customize timeouts per task and per flow.
Automatic retries

Render automatically retries a failed task run or flow step according to its settings.
Flexible compute

Set CPU and RAM per task and flow. Pay only for the resources you use with the flex plan.
Rich observability

Track the status of active and completed runs in the Render Dashboard.
CLI integration

Create new workflow services, trigger runs, and view run history from the command line.
Rapid local development

Quickly iterate on your task logic by spinning up a local task server.

What's in a workflow?

A workflow service contains a collection of function definitions that you register with Render. You designate each function as one of two types: a task or a flow.

Type	Description
Task	A single unit of work that executes in its own instance. Tasks can chain runs of additional tasks to distribute work across multiple instances.
Flow	A sequence of steps that run in order, all on a single instance. Flows persist the return value of each step. If an infrastructure issue interrupts a flow run, Render automatically replays it from the beginning and reuses the return values from completed steps.

Type

Description

Task

A single unit of work that executes in its own instance.

Tasks can chain runs of additional tasks to distribute work across multiple instances.

Flow

A sequence of steps that run in order, all on a single instance.

Flows persist the return value of each step. If an infrastructure issue interrupts a flow run, Render automatically replays it from the beginning and reuses the return values from completed steps.

After you register your tasks and flows, you can trigger individual runs of your functions using the Render SDK or API:

Each run executes in its own instance, which Render spins up on demand within seconds. If you trigger more simultaneous runs than your workflow's compute limits allow, Render queues up the excess until resources become available.

A run executes whatever logic you define in its function. For tasks, this can include chaining runs of other tasks in the same workflow:

run_agent()30s

gather_context()

execute_skills()

compose_response()

fetch_docs()

search_web()

In this example, we trigger a run of the run_agent task. This task chains runs of other tasks (gather_context, execute_skills, and so on). Each run in the chain also executes in its own instance.

The run_agent task depends on the results of its various chained runs, so it awaits their completion before chaining additional runs and eventually returning its own result.

Defining tasks and flows

Every workflow service pulls its task and flow definitions from a Git provider repo. In this repo, you define tasks and flows as TypeScript or Python functions using the Render SDK.

Here's a single-file workflow definition that defines two basic tasks:

index.ts

typescript

import { task, type TaskContext } from '@renderinc/sdk/workflows'

// Basic task that takes one argument
const calculateSquare = task(
  { name: 'calculateSquare' },
  function calculateSquare(ctx: TaskContext, a: number): number {
    return a * a
  }
)

// Task that chains two parallel runs of calculateSquare
const sumSquares = task(
  { name: 'sumSquares' },
  async function sumSquares(ctx: TaskContext, a: number, b: number): Promise<number> {
  
    // Parallelize with Promise.all
    const [result1, result2] = await Promise.all([
      ctx.run(calculateSquare, a),
      ctx.run(calculateSquare, b)
    ])

    // Return the sum of the two results
    return result1 + result2
  }
)

main.py

python

from render import TaskContext, Workflows
import asyncio

app = Workflows()

# Basic task that takes one argument
@app.task
def calculate_square(ctx: TaskContext, a: int) -> int:
  return a * a

# Task that chains two parallel runs of calculate_square
@app.task
async def sum_squares(ctx: TaskContext, a: int, b: int) -> int:

  # Parallelize with asyncio.gather
  result1, result2 = await asyncio.gather(
    ctx.run(calculate_square, a),
    ctx.run(calculate_square, b)
  )

  # Return the sum of the two results
  return result1 + result2

if __name__ == "__main__":
  app.start()

You can define tasks and flows across any number of files and directories, importing frameworks and libraries as needed.

As part of registering your tasks and flows, Render builds your project into a custom image and caches it. Render pushes this image to each run's instance as part of spin-up.

Create your first workflow

Triggering runs

You trigger runs of your tasks and flows from anywhere using the Render SDK or API:

client_app.ts

typescript

import { Render } from '@renderinc/sdk'

const render = new Render()

// Trigger a run of calculateSquare with the argument `2`
const startedRun = await render.workflows.startTask(
  'my-workflow/calculateSquare',
  [2],
)
const finishedRun = await startedRun.get()
console.log(finishedRun.results)

client_app.py

python

from render import RenderAsync

render = RenderAsync()

# Trigger a run of calculate_square with the argument `2`
started_run = await render.workflows.start_task(
  "my-workflow/calculate_square",
  [2],
)
finished_run = await started_run
print(finished_run.results)

client_app.py

python

from render import Render

render = Render()

# Trigger a run of calculate_square with the argument `2`
finished_run = render.workflows.run_task(
  "my-workflow/calculate_square",
  [2],
)
print(finished_run.results)

In any environment where the Render SDK isn't available, you can trigger runs directly via the Render API. Here's an example curl command for triggering a task run:

bash

# Trigger a run of calculate_square with the argument `2`
curl -X POST https://api.render.com/v1/task-runs \
  -H "Authorization: Bearer rnd_abc123..." \
  -H "Content-Type: application/json" \
  -d '{"task": "my-workflow/calculate_square", "input": [2]}'

All versions of the Render SDK call the Render API under the hood to trigger runs.

For all the details, see Triggering Workflow Runs.

Workflows versus job queues

Historically, job queue architectures (as managed by Celery, BullMQ, etc.) have required setting up multiple pieces of infrastructure and configuring them to work together:

Diagram of a background worker polling a task queue

Render Workflows unifies this architecture into a single, fully managed system:

Role	Traditional job queue	Render Workflows
Task submission	You deploy a custom web service that listens for incoming requests and enqueues workloads.	Trigger runs from anywhere using the Render SDK or API.
Queue management	You manage your own queue state in a Render Key Value instance or similar datastore.	Render manages your task queue at no additional cost.
Worker provisioning	You maintain a fleet of always-running background workers that pull and execute tasks.	Render provisions workers on demand and scales to zero when all runs finish.

For new projects that require long-running background execution, Render Workflows helps you move faster with fewer moving parts.

Create your first workflow

FAQ

How do I get started with Render Workflows?

Get started with Your First Workflow.

Which languages can I use to define tasks and flows?

You define tasks and flows with the Render SDK, which is currently available for TypeScript and Python.

SDKs for additional languages are planned for future releases.

Can I trigger runs without using the Render SDK?

Yes! You can trigger runs via the Render SDK, API, CLI, or Dashboard.

For details, see Triggering Workflow Runs.

Can runs interact with my other Render services?

Yes! Runs can initiate connections to your other Render services and datastores in the same region via private networking.

Can runs receive incoming network connections?

No. Similar to Render's background worker service type, runs do not expose any ports. They initiate any network connections they need.

Can I use Render Workflows with Blueprints?

Yes! You can create and manage workflows with Blueprints, Render's infrastructure-as-code model.

You include workflow definitions alongside other services in your Blueprint file's services list. For example:

yaml

services:
  - type: workflow
    name: support-agent
    runtime: python
    region: oregon
    buildCommand: pip install -r requirements.txt
    startCommand: python main.py

See the Blueprint YAML Reference for workflow-specific field support.

Workflows do not yet support preview environments or Blueprint replication.

Render automatically skips creating preview copies of workflows when preview environments are enabled for a Blueprint.
Render rejects a Blueprint that defines a workflow with the same name as an existing Blueprint-managed workflow.

How are workflows billed?

Workflows are billed for the compute usage of each run, based on compute plan and duration. They are also billed for temporary retention of each run's arguments and return value.

For details, see Limits and Pricing for Render Workflows.

What are the known limitations of Render Workflows?

We'll address these limitations in future releases:

Workflows currently only support TypeScript and Python for defining tasks and flows.
- SDKs for other languages are planned for future releases.
Workflows do not yet natively support scheduling runs.
- To schedule runs, you can create a cron job that triggers runs on the desired schedule.
Flows are not yet able to chain runs of other tasks or flows.
Workflows do not yet support preview environments or Blueprint replication. For details, see Can I use Render Workflows with Blueprints?.
If a workflow belongs to a network-isolated environment, its runs cannot communicate with other services in that environment over its private network.
Workflows do not yet support HIPAA-compliant hosts.
- To prevent accidental PHI exposure, it is not currently possible to create new workflows in a HIPAA-enabled workspace.
- If you enable HIPAA compliance for a workspace that already has workflows, do not process PHI in workflow runs.
Flows are not yet available in the Oregon region for workspaces created before January 23, 2022.