In this step you’ll deploy the workflow to Render and trigger it remotely. The local script you wrote in step 3 keeps working. You just point it at the deployed service.
Push your fork
Render needs access to a repo you control. Fork render-examples/data-processor-workflow, point your local clone at the fork, and push your branch. If you already pushed your copy to GitHub, skip the fork command and keep using your existing remote.
$gh repo fork render-examples/data-processor-workflow --clone=falseCreated fork <your-user>/data-processor-workflow$git remote set-url origin git@github.com:<your-user>/data-processor-workflow.git$git push -u origin main
Create the Workflow service
- In the Render Dashboard, click New → Workflow.
- Connect your forked repo.
- Set the Root Directory and build/start commands for your chosen language (see below).
- Click Deploy Workflow and wait for the first build to finish.
- On the service page, copy the workflow slug. You’ll need it in your trigger script.
| Field | Value |
|---|---|
| Name | data-processor-workflows-py |
| Language | Python 3 |
| Root Directory | python/workflows |
| Build Command | pip install -r requirements.txt |
| Start Command | python main.py |
| Field | Value |
|---|---|
| Name | data-processor-workflows-ts |
| Language | Node |
| Root Directory | typescript/workflows |
| Build Command | npm install && npm run build |
| Start Command | npm start |
Add DATA_DIR=../../sample_data on the Workflow service’s Environment tab before the first run. The workflow starts from python/workflows or typescript/workflows, and the sample CSVs live two directories up. For this tutorial, committing the small 1K-row sample_data/ folder is the simplest deploy path. In a real ETL, replace load_csv(filename) with a reader for S3, a database, or another durable source.
Trigger the deployed workflow
Turn off local dev mode, set your Render API key and workflow slug, then run the same trigger script you used locally.
$export RENDER_API_KEY=<your-render-api-key>$export WORKFLOW_SLUG=data-processor-workflows-py$unset RENDER_USE_LOCAL_DEV && python trigger.pyRun started: <run-id> Merged 1000 enriched profiles across 10 shards in 1.4s
$export RENDER_API_KEY=<your-render-api-key>$export WORKFLOW_SLUG=data-processor-workflows-ts$unset RENDER_USE_LOCAL_DEV && npx tsx trigger.tsRun started: <run-id> Merged 1000 enriched profiles across 10 shards in 1.4s
Open the Workflow service’s Runs tab and click the run id from your terminal. A healthy run shows one parent row for merge_customer_data and one child row per process_shard subtask. All rows should finish green, and each child row should show stdout from its shard.
What you learned
- Workflow services are created in the Render Dashboard. Blueprints don't cover them yet
- Each language has its own Root Directory and build/start command pair
- Your trigger script works locally and remotely. Only env vars change
- The Runs tab in the Render Dashboard shows one parent task plus one row per shard subtask