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: <YOUR_USERNAME>-agents-workshop-workflows
    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: <YOUR_USERNAME>-agents-workshop-workflows
    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.

Two things to get right, or the rest of the tutorial fights you: attach the service to your project, and name it with your username first.

First, get to the New Workflow form:

1. Open your project Click into the project the Blueprint just created.
2. Add a new service From inside the project, click + New service and choose Workflow. Starting from inside the project pre-fills the Project field, so the service lands next to the gateway and database. If you start from the top nav instead, the field is empty and you must pick your project from the Project dropdown before you deploy, or the services split apart.
3. Select your fork

   Choose your connected workflow workshop repo.

   

Then set every field. Type each value exactly, character for character. Root Directory, Build Command, and Start Command are where attendees slip, and a wrong value here is what fails the build later.

With the fields set, finish the service:

1. Wire DATABASE_URL On the Environment tab, set DATABASE_URL to the internal connection string for <your-username>-workflow-agents-db, the same database the gateway uses.
2. Link the environment group

   On the same Environment tab, scroll to Linked Environment Groups, pick workflow-shared-keys from Link Environment Group, and click Link, rebuild, and register. This is how the workflow service receives the workshop OPENAI_API_KEY without pasting it by hand.

   

3. Deploy the workflow service Click Deploy workflow. The first deploy takes a couple of minutes. Wait for the service to show as live before proceeding — the gateway can’t dispatch runs until the workflow service has registered its tasks.

Confirm the workflow service landed in the same project as the gateway. If the two services split apart, you started the + New flow from outside the project.

render workflows create \
  --name <your-username>-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" \
  --output json \
  --confirm

render workflows create \
  --name <your-username>-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" \
  --output json \
  --confirm

render workflows deploy --name <your-username>-workflow-agents

render workflows list

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. It’s your personal slug, so it can’t live in the shared group. 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 <your-username>-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.

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 localhost Workshop: 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