Intro to Render Workflows

Orchestrate chains of long-running, distributed tasks.

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

Define tasks as standard functions with Render's lightweight SDK, then dispatch 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()

onboard_employee()40s

provision_user()

enroll_benefits()

add_to_payroll()

create_accounts()

run_etl_pipeline()120s

extract_orders()

load_warehouse()

clean_orders()

enrich_orders()

process_batch()120s

process_item(1)

aggregate()

process_item(…)

process_item(n)

Your workflow service handles task queuing, scheduling, and compute for you, all managed together on Render infrastructure.

At a glance

You define your tasks as standard TypeScript or Python functions and register them with Render.
Trigger task 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 task run and deprovisions instances as runs complete.
- If a task run fails, Render automatically retries it according to your settings.

Render only bills you for compute usage (prorated by the second) and for optionally increasing your workspace's maximum number of concurrent task runs. Render queues and provisions your task runs at no additional cost.

Create your first workflow

Core features

Tasks as functions

Define tasks with the Render SDK. Chain tasks by calling one task's function from another.
Managed orchestration

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

Each task run can execute for up to 24 hours. You can customize this per task.
Automatic retries

If a task run fails, Render automatically retries it according to your settings.
Per-task compute specs

Use larger instance types for your most resource-intensive workloads.
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 is a collection of tasks that you define as code and register with Render:

A list of registered tasks in the Render Dashooard

Execution flow

After you create your workflow service, you can trigger individual runs of its tasks using the Render SDK or API:

Each run executes in its own instance, which Render spins up on demand within seconds. If your workspace is already running its maximum number of concurrent tasks, Render instead keeps the run in a queue until another run completes.

A task executes whatever logic you define in its function. 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's logic includes chaining 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

Every workflow service pulls its task definitions from a GitHub/GitLab/Bitbucket repo. In this repo, you define tasks 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 } from '@renderinc/sdk/workflows'

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

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

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

main.py

python

from render_sdk import Workflows
import asyncio

app = Workflows()

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

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

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

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

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

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

Create your first workflow

Triggering runs

You trigger task runs 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_sdk 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_sdk 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 task runs directly via the Render API. Here's an example curl command:

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 task runs.

For all the details, see Triggering Task 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 task 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

Render Workflows is in public beta.

We're continuing to expand tooling and observability capabilities during the beta period. We welcome all feedback at workflows-feedback@render.com.

How do I get started with Render Workflows?

Get started with Your First Workflow.

Which languages can I use to define workflow tasks?

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

SDKs for additional languages are planned for future releases.

Can I trigger task runs without using the Render SDK?

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

For details, see Triggering Task Runs.

Can task runs interact with my other Render services?

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

Can my task runs receive incoming network connections?

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

How are workflows billed?

Workflows are billed for the compute usage of each task run, based on instance type and duration. For an additional monthly cost, you can increase your workspace's max allowed number of concurrent task runs.

For details, see Limits and Pricing for Render Workflows.

What limitations are in place during the Workflows beta?

We'll address these limitations in future releases after the beta:

Workflows currently only support TypeScript and Python for defining tasks.
- SDKs for other languages are planned for future releases.
Workflows do not yet natively support scheduling task runs.
- To schedule runs, you can create a cron job that runs your tasks on the desired schedule.
Blueprints do not yet support creating or managing workflows.
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 running tasks on 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 tasks.