Deploy the workflow agents

Pattern 3 deploys as two services. A gateway web service receives PR submissions and dispatches workflow runs. A workflow service registers and runs the tasks. The Blueprint creates the gateway; the workflow service is a separate Dashboard step because Blueprints do not yet create or manage Workflows.

flowchart LR
  pr(["PR URL"])
  gw["Gateway<br/>web service"]
  wf["Workflow service<br/>runs the tasks"]

  pr --> gw
  gw -->|dispatch run| wf
  wf --> cr["code-review task"]

Inside the run, the built-in code-review task runs prepare diff and filter diff as plain functions, then fans out security, performance, and ux (frontend only) as their own tasks, and ends with judge.

1. Deploy the gateway Blueprint

The Pattern 3 Blueprint provisions the gateway web service and a Postgres database.

projects:
  - name: workflow-agents
    environments:
      - name: production
        databases:
          - name: <YOUR_USERNAME>-workflow-agents-db
            plan: basic-256mb
            region: oregon
            postgresMajorVersion: "18"

        services:
          - type: web
            name: <YOUR_USERNAME>-agents-gateway
            runtime: node
            region: oregon
            plan: starter
            buildCommand: npm ci
            startCommand: npm run start --workspace @workshop/workflow-agents
            healthCheckPath: /healthz
            envVars:
              - key: DATABASE_URL
                fromDatabase:
                  name: <YOUR_USERNAME>-workflow-agents-db
                  property: connectionString
              - fromGroup: workflow-shared-keys
              - key: NODE_ENV
                value: production

projects:
  - name: workflow-agents
    environments:
      - name: production
        databases:
          - name: <YOUR_USERNAME>-workflow-agents-db
            plan: basic-256mb
            region: oregon
            postgresMajorVersion: "18"

        services:
          - type: web
            name: <YOUR_USERNAME>-agents-gateway
            runtime: python
            region: oregon
            plan: starter
            buildCommand: pip install uv && uv sync --frozen --no-dev --package workshop-workflow-agents
            startCommand: uv run python -m workflow_agents.server
            healthCheckPath: /healthz
            envVars:
              - key: DATABASE_URL
                fromDatabase:
                  name: <YOUR_USERNAME>-workflow-agents-db
                  property: connectionString
              - fromGroup: workflow-shared-keys
              - key: NODE_ENV
                value: production
              - key: PYTHON_VERSION
                value: "3.12"

The gateway writes review rows to Postgres and dispatches real Render Workflow runs. DATABASE_URL comes from <YOUR_USERNAME>-workflow-agents-db. Shared secrets such as RENDER_API_KEY and OPENAI_API_KEY come from the workflow-shared-keys environment group.

1. Start a new Blueprint In the Render Dashboard, click + New, then Blueprint. If you haven’t connected GitHub yet, click Connect GitHub and authorize the Render app for your fork.
2. Select your fork Pick your workflow workshop fork from your connected repos.
3. Set the Blueprint Path Set it to your track’s Pattern 3 path, exactly: packages/workflow-agents/render.yaml (TypeScript) or packages/workflow_agents/render.yaml (Python). Mind the hyphen vs underscore. There’s no root render.yaml.
4. Create all as new services

   Then click Deploy Blueprint. You get the gateway web service and Postgres.

   

2. Create the workflow service

This is the step that is easy to miss. The workflow service runs the workflow entrypoint, which registers and executes the tasks. The Blueprint does not create it.

Name the service workflow-agents to match the slug you’ll wire into the gateway.

The CLI is the fastest route. One command sets every field, so there’s nothing to mistype in a form. First make sure you’re logged in and pointed at your workspace (see the CLI setup note in Section 3), then have your repo URL, branch, and the internal connection string for workflow-agents-db ready.

render workflows create \
  --name workflow-agents \
  --repo <your-repo-url> \
  --branch <your-branch> \
  --root-directory packages/workflow-agents \
  --runtime node \
  --region oregon \
  --build-command "cd ../.. && npm ci" \
  --run-command "cd ../.. && npm run start:workflow --workspace @workshop/workflow-agents" \
  --env-var DATABASE_URL=<internal-postgres-connection-string> \
  --env-var NODE_ENV=production \
  --output json \
  --confirm

render workflows create \
  --name workflow-agents \
  --repo <your-repo-url> \
  --branch <your-branch> \
  --root-directory packages/workflow_agents \
  --runtime python \
  --region oregon \
  --build-command "pip install uv && uv sync --frozen --no-dev" \
  --run-command "uv run python -m workflow_agents.workflow" \
  --env-var DATABASE_URL=<internal-postgres-connection-string> \
  --env-var PYTHON_VERSION=3.12 \
  --output json \
  --confirm

Confirm the service exists and read back its slug:

render workflows list

It should list workflow-agents. That exact slug is what you wire into the gateway in Section 3.

Provider keys (OPENAI_API_KEY / ANTHROPIC_API_KEY) are optional: without them the task uses the mock model. For real findings, add --env-var OPENAI_API_KEY=<key> to the command, or set them on the service’s Environment tab in the Dashboard.

3. Set the workflow slug on the gateway

The gateway needs one value from you: RENDER_WORKFLOW_SLUG, the name of the workflow service you just created. Everything else is already wired:

Set the slug:

1. Copy the workflow slug

   Open your workflow service’s page. Next to Workflow Slug, click the copy icon. It should read workflow-agents.

   

2. Add the env var on the gateway Open the <your-username>-agents-gateway web service, go to the Environment tab, and click + Add variable.
3. Type the key and paste the slug

   In the KEY field, type RENDER_WORKFLOW_SLUG exactly. In the VALUE field, paste the slug you copied. Don’t type it from memory: a typo dispatches to a slug that doesn’t exist.

   

4. Save and redeploy Click Save, rebuild, and deploy.

Set RENDER_WORKFLOW_SLUG to workflow-agents (the name of the workflow service you created in Section 2).

After the Workflow service deploys, confirm the task is registered:

render workflows tasks list

In the interactive CLI, this opens a short wizard: pick your workflow (for example <your-username>-workflow-agents), then pick the ready version, then read the Tasks table. The first screen looks like a workflow list; that is expected. Success means you reach Tasks and see names such as code-review, security, performance, ux, judge, my-reviewer, and your-review.

In a non-interactive terminal (some IDE shells), pass the version id explicitly:

render workflows versions list <your-username>-workflow-agents -o text
render workflows tasks list <wfv-id> -o text

These commands hit the Render API, not localhost: do not pass --local.

4. Paste a PR link into the gateway and read the trace

You don’t open a pull request here. You paste the URL of an existing PR into the gateway dashboard, and the gateway reviews it for you.

Open the gateway’s *.onrender.com URL. You’ll see the Workflow Agents dashboard. Copy the link to the LlamaIndex baseline PR and paste it into the dashboard. The gateway dispatches the hosted code-review workflow and creates a review row immediately.

1. Paste the PR link Paste the PR URL into the field in the gateway dashboard and click Review. The gateway returns quickly and creates a review row instead of blocking on the whole run.
2. Open the run trace In the Render Dashboard, open the workflow service and find the run.
3. Read the fan-out Each reviewer is its own task. The parallel reviewers fan out, each in its own isolated container, then judge merges their findings.

The gateway dashboard is useful for the review record: status, verdict, tokens, run time, reason, findings, and spans. The Render Dashboard is where you inspect the Workflow run trace itself.

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

The LlamaIndex baseline touches backend files, so security and performance run but ux is skipped. Paste the Mastra frontend PR link into the dashboard, or pick it from the dashboard picker, to watch the ux task join the fan-out.

Everything you see in that trace, the queueing, the per-task retries and timeouts, the isolation, the parallel fan-out, is what you hand-wrote in the queue helper for Pattern 2. Here it’s the platform.

# Build Command
cd ../.. && npm ci

# Start Command
cd ../.. && npm run start:workflow --workspace @workshop/workflow-agents