From render
Sets up, develops, tests, and deploys Render Workflows including scaffolding via CLI/manual, Python/TypeScript SDK installation, task patterns (retries, subtasks, fan-out), local development, Dashboard deployment, and troubleshooting.
npx claudepluginhub render-oss/skills --plugin renderThis skill uses the workspace's default tool permissions.
Render Workflows rapidly distribute computational work across multiple independent instances.
Generates design tokens/docs from CSS/Tailwind/styled-components codebases, audits visual consistency across 10 dimensions, detects AI slop in UI.
Records polished WebM UI demo videos of web apps using Playwright with cursor overlay, natural pacing, and three-phase scripting. Activates for demo, walkthrough, screen recording, or tutorial requests.
Delivers idiomatic Kotlin patterns for null safety, immutability, sealed classes, coroutines, Flows, extensions, DSL builders, and Gradle DSL. Use when writing, reviewing, refactoring, or designing Kotlin code.
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.