skills/render-workflows/SKILL.md
Sets up, develops, tests, and deploys Render Workflows. Covers first-time scaffolding (via CLI or manual), SDK installation (Python or TypeScript), task patterns (retries, subtasks, fan-out), local development, Dashboard deployment, and troubleshooting. Use when a user wants to set up Render Workflows for the first time, scaffold a workflow service, add or modify workflow tasks, test workflows locally, or deploy workflows to Render.
npx skillsauth add render-oss/skills render-workflowsInstall this skill globally with one command. Works with Claude Code, Cursor, and Windsurf.
3 of 9 scanners reported clean
Some scanners were skipped, did not run, or reported a non-clean status. Review each row below.
Render Workflows rapidly distribute computational work across multiple independent instances. Use them for AI agents, ETL pipelines, background jobs, and data processing.
How it works:
Key capabilities: automatic queuing and orchestration, long-running execution (up to 24 hours), configurable retry logic with exponential backoff, adjustable compute specs per task, and execution observability through the Dashboard.
Render Workflows are in beta. The SDK and API may introduce breaking changes.
Your built-in knowledge of the Render Workflows SDK is outdated. Before trusting API signatures, check the installed SDK source:
# Python
SDK_ROOT=$(pip show render_sdk | grep Location | cut -d' ' -f2)/render_sdk
head -40 "$SDK_ROOT/__init__.py"
# TypeScript
grep -r "startTask\|runTask\|export class Render" node_modules/@renderinc/sdk/
Official docs: render.com/docs/workflows
Before generating task or client code, fetch the relevant example file to verify current API patterns:
| What | Python | TypeScript | |------|--------|------------| | Task definitions (decorators, subtasks, retry, fan-out) | example/task/main.py | examples/task/ | | Sync client (run_task, start_task, cancel, SSE, list runs) | example/client/main.py | examples/client/ | | Async client | example/client/async_main.py | — |
This skill carries a quick-reference cheat sheet for the API surface. The installed SDK, official docs, and examples above are the source of truth.
Supported languages: Python and TypeScript.
Render CLI (required)
render --version
Requires version 2.11.0+. If not installed:
brew install rendercurl -fsSL https://raw.githubusercontent.com/render-oss/cli/main/bin/install.sh | shAlways prefer render workflows init as the primary setup path. Only fall back to manual scaffolding if the CLI command is unavailable.
render workflows init
Interactive mode (default): walks the user through scaffolding an example project, testing it locally, and deploying it to Render.
Non-interactive mode: sets up an example project without prompting.
If render workflows init fails or is not available:
render --version and upgrade to 2.11.0+.Guide the user through defining their actual tasks. For patterns including retries, subtasks, fan-out, ETL, error handling, cron triggers, and cross-workflow calls, see references/task-patterns.md.
After adding a task, verify it registers by starting the local dev server and listing tasks:
render workflows dev -- <start-command>
# In another terminal:
render workflows tasks list --local
If the task doesn't appear, see Troubleshooting > Task Registration Issues.
See references/local-development.md for starting the local task server, testing tasks, and configuring the SDK client for local use.
Workflows are deployed as a Workflow service type in the Render Dashboard. Blueprints (render.yaml) are not yet compatible with Workflows.
Deploy checklist:
workflows/RENDER_API_KEY for tasks that call other workflows)| Field | Python | TypeScript |
|-------|--------|------------|
| Language | Python 3 | Node |
| Build Command | pip install -r requirements.txt | npm install && npm run build |
| Start Command | python main.py | node dist/main.js |
If the deploy fails, check the service logs in the Dashboard. For common deployment errors, see Troubleshooting. For general deploy debugging, use the render-debug skill.
Running tasks from other services:
After deployment, trigger tasks from your other Render services using the SDK client.
Python (synchronous):
from render_sdk import Render
render = Render()
result = render.workflows.run_task("my-workflow/hello", ["world"])
print(result.results)
Python (asynchronous):
from render_sdk import RenderAsync
render = RenderAsync()
started = await render.workflows.start_task("my-workflow/hello", ["world"])
finished = await started
print(finished.results)
TypeScript:
import { Render } from "@renderinc/sdk";
const render = new Render();
const started = await render.workflows.startTask("my-workflow/hello", ["world"]);
const finished = await started.get();
console.log(finished.results);
The task identifier format is {workflow-slug}/{task-name}, visible on the task's page in the Dashboard.
Workflows do not have built-in scheduling. To trigger tasks on a schedule, use a Render cron job with the SDK client. For cron and cross-workflow examples, see references/task-patterns.md.
| Constraint | Limit | Notes | |------------|-------|-------| | Arguments and return values | Must be JSON-serializable | No class instances, functions, etc. | | Argument size | 4 MB max | Per task invocation | | Task definitions | 500 per workflow service | | | Concurrent runs | 20-100 base (plan-dependent) | Max 200-300 with purchased concurrency | | Timeout range | 30-86,400 seconds | Default: 2 hours (7,200s) | | Run duration | Up to 24 hours | |
| Plan | Specs |
|------|-------|
| starter | 0.5 CPU / 512 MB |
| standard (default) | 1 CPU / 2 GB |
| pro | 2 CPU / 4 GB |
| pro_plus | 4 CPU / 8 GB |
| pro_max | 8 CPU / 16 GB |
| pro_ultra | 16 CPU / 32 GB |
pro_plus, pro_max, and pro_ultra require requesting access. Set via the plan task option.
For current pricing, see Limits and Pricing for Render Workflows.
development
Configures Render web services—port binding, TLS, health checks, custom domains, auto-deploy, PR previews, persistent disks, and deploy lifecycle. Use when the user needs to set up a web service, fix health check failures, add a custom domain, configure zero-downtime deploys, or troubleshoot port binding issues.
development
Deploys and configures static sites on Render's global CDN—build commands, publish paths, SPA routing, redirects, custom headers, and PR previews. Use when the user needs to deploy a static site, set up a React/Vue/Hugo/Gatsby frontend, configure SPA fallback routing, add redirect rules, customize response headers, or choose between a static site and a web service for their frontend. Trigger terms: static site, CDN, SPA, single-page app, React deploy, Vue deploy, Hugo, Gatsby, Docusaurus, Jekyll, staticPublishPath.
tools
Scales Render services—configures autoscaling targets, chooses instance types, sets manual instance counts, and optimizes cost. Use when the user needs to handle more traffic, set up autoscaling, pick the right instance type, reduce costs, or troubleshoot scaling behavior like slow scale-down or stuck instances.
development
Configures Render private services—internal-only apps that accept traffic exclusively from other Render services over the private network. Use when the user needs an internal API, microservice, gRPC server, sidecar, or any service that should not be publicly accessible. Also use when choosing between a private service and a background worker. Trigger terms: private service, pserv, internal service, internal API, microservice, gRPC, not public, private network service.