Render Tutorials
ETL on Workflows, Part 2: Productionize and scale it

Deploy the workflow to Render

⏱ 8 min

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.

Terminal
$gh repo fork render-examples/data-processor-workflow --clone=false
Created 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

  1. In the Render Dashboard, click NewWorkflow.
  2. Connect your forked repo.
  3. Set the Root Directory and build/start commands for your chosen language (see below).
  4. Click Deploy Workflow and wait for the first build to finish.
  5. On the service page, copy the workflow slug. You’ll need it in your trigger script.
FieldValue
Namedata-processor-workflows-py
LanguagePython 3
Root Directorypython/workflows
Build Commandpip install -r requirements.txt
Start Commandpython main.py
FieldValue
Namedata-processor-workflows-ts
LanguageNode
Root Directorytypescript/workflows
Build Commandnpm install && npm run build
Start Commandnpm 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.

Terminal
$export RENDER_API_KEY=<your-render-api-key>
$export WORKFLOW_SLUG=data-processor-workflows-py
$unset RENDER_USE_LOCAL_DEV && python trigger.py
Run started: <run-id> Merged 1000 enriched profiles across 10 shards in 1.4s
Terminal
$export RENDER_API_KEY=<your-render-api-key>
$export WORKFLOW_SLUG=data-processor-workflows-ts
$unset RENDER_USE_LOCAL_DEV && npx tsx trigger.ts
Run 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