Run workflows locally (Optional)

The hosted deploy proves Pattern 3 works in production. Before you author anything, set up the local loop, because a fast edit-run cycle beats a deploy between every change. Render Workflows run under a local dev runtime that gives each task the same isolation, retries, and fan-out you saw in the Dashboard.

1. Install the Render CLI

You need the CLI to run tasks under the local dev runtime. Version 2.11.0 or newer has the workflow subcommands.

brew install render
brew upgrade render

curl -fsSL https://raw.githubusercontent.com/render-oss/cli/main/bin/install.sh | sh

$render --version
render version 2.11.0 (or newer)

After installing, confirm you’re on the latest CLI: render --version. If it’s below 2.20, run brew upgrade render. If which render points at ~/.local/bin/render, put Homebrew earlier in your PATH or remove the old install.

2. Start the local workflow runtime

From your fork:

npm ci
cd packages/workflow-agents
cp .env.example .env
npm run dev:workflows

uv sync
cp .env.example .env
cd packages/workflow_agents
render workflows dev -- uv run python -m workflow_agents.workflow

The terminal may look like it hangs after the last command — that’s expected. The workflow server is running and listening for tasks. You’ll see output once you trigger a task in the next step.

This starts the local Render task runtime. Each task runs in isolation, with real retries and fan-out, against your machine. No database or API key is required: telemetry falls back to in-memory and the agent falls back to the mock model. Set OPENAI_API_KEY in .env for real findings.

3. List and run a task

Open a second terminal (keep Terminal A running) and list the registered tasks. The loader auto-discovers the workflow modules for your track, so you’ll see the workflows and the per-agent tasks with no registration step:

render workflows tasks list --local

You should see the task names printed. Now run the built-in code-review task against the LlamaIndex baseline PR. The trace shows the review tasks fan out and rejoin before judge returns the verdict:

render workflows tasks start code-review --local \
  --input='[{"url":"https://github.com/run-llama/LlamaIndexTS/pull/2234","labels":[]}]'

render workflows tasks start code_review --local \
  --input='[{"url":"https://github.com/run-llama/LlamaIndexTS/pull/2234","labels":[]}]'

Watch the render workflows dev output. You get the same tree you read in the hosted Dashboard trace, now on your laptop:

flowchart TB
  cr["code-review<br/>task"]
  cr --> sec["security<br/>task"]
  cr --> perf["performance<br/>task"]
  cr --> ux["ux<br/>task (frontend diff)"]
  sec --> judge["judge<br/>task"]
  perf --> judge
  ux --> judge

Each task runs in its own isolated process, with its retries and timeouts applied, exactly like production. That’s what makes this a real loop and not a toy: what you see locally is what ships.

This page uses the CLI path because it keeps the task fan-out visible in the terminal. The gateway dashboard you deployed in the previous step is the same UI; running it locally is optional and takes its own terminal (npm run dev for TypeScript, uv run python -m workflow_agents.server for Python), since the dev command above runs only the task runtime.