Workflows: Create the Workflow service

Last build step. Create the Render Workflow that runs tasks/ from your fork, set WORKFLOW_SERVICE_SLUG on the web service, then verify end-to-end.

Up to this point, we called this the “second service.” In Render’s product UI and docs, it is named a Workflow service.

You should already have:

• searchOne in task() and tasks/src/index.ts (Workflow entrypoint).
• research.ts using startTask + getTaskRun (dispatch from web).
• Web service redeployed with workflow dispatch code.

Push latest code

Push your workshop-demo fork to GitHub. The Workflow builds from the tasks/ directory in that repo.

$git push origin main
Everything up-to-date

Open New Workflow

In the Render Dashboard:

1. Click New (top right) → Workflow.
2. You land on New Workflow (Beta). Use Read docs if you want the platform overview first.

Connect Source Code to your fork of workshop-demo (the same repo as your web service). If the wrong repo is selected, click Edit and reconnect.

Fill the form (top to bottom)

Work through the page in order. Render blocks Deploy Workflow until required fields pass validation (you may see There are errors above. Please fix them to continue.).

Environment Variables (same page)

Scroll to Environment Variables before you deploy:

1. Click Add Environment Variable.
2. Key: EXA_API_KEY. Value: your key from the Exa dashboard.
3. You can also use Add from .env if you have a local .env in tasks/.

searchOne runs Exa inside the Workflow process. After this deploy works, remove EXA_API_KEY from the web service if it is still set from the baseline.

Retries, timeout, and instance plan for searchOne come from your task() config in code (step Register searchOne with retries).

Advanced

Under Advanced, leave Guaranteed Warm Start Disabled unless you want a always-on instance (+$25/month). The tutorial does not need it.

Deploy Workflow

1. Confirm Start Command is filled in and Root Directory is tasks.
2. Click Deploy Workflow.
3. First build takes a couple of minutes. Open Logs or Events on the new service until status is Live.

If deploy fails, check Logs for a bad root directory, a failed npm run build, or a missing import in tasks/src/index.ts.

Confirm tasks registered

After the deploy is Live:

1. Open the Workflow service in the Dashboard.
2. Go to the Tasks tab.
3. Confirm searchOne appears in the list.
4. Click searchOne. At the top you should see the task identifier as your-workflow-slug/searchOne. That slug prefix is what startTask expects.

Copy the workflow slug

1. Open the Workflow service Settings tab.
2. Copy the workflow slug (derived from Name, e.g. ticker-research-workflows or ticker-research-workflows-aBc1XyZ if Render added a suffix).

This must match WORKFLOW_SERVICE_SLUG on the web service exactly.

Wire the web service

On your web service:

1. Open Environment Web service → Environment tab.
2. Set WORKFLOW_SERVICE_SLUG Paste the slug from the Workflow Settings tab. No trailing slash.
3. Confirm RENDER_API_KEY and ANTHROPIC_API_KEY Both must be set. The web service uses the API key to start runs and Anthropic for memo synthesis.
4. Save and redeploy Save, rebuild, and deploy, or Manual Deploy → deploy latest commit.

Verify end-to-end

1. Open your web URL.
2. Query TSLA.
3. All four search cards reach Done.
4. On the Workflow service, open Runs → filter or click searchOne. You should see four runs per query, with retries when maybeFail fires.
5. The memo streams and completes.

Dashboard stuck but Runs show completed: the web service is still polling. That usually means WORKFLOW_SERVICE_SLUG does not match the slug in Settings, or the web service was not redeployed after you set it.

Optional debug before the full UI: on the Workflow service, use Run manually for searchOne with JSON args:

["TSLA", { "query": "TSLA stock news", "label": "News" }, 0]

Adjust the middle object to match a real SearchSpec from your code. A succeeded run here means the Workflow service is healthy; if the UI still fails, debug the web service env vars and dispatch code.

Redeploy after Workflow code changes

When you change files under tasks/:

1. Push to your fork (auto-deploy runs if Auto-Deploy is On Commit).
2. Or on the Workflow service: Manual Deploy → deploy latest commit.
3. After the deploy finishes, check Tasks again if you added or renamed a task.

Reuse the same Workflow for routine code changes. Keep the same slug and WORKFLOW_SERVICE_SLUG.