Worker Managers

Worker managers handle the provisioning and destruction of worker resources. They bridge Scaler’s scaling policies and the underlying infrastructure — local processes, cloud instances, or container orchestrators.

Note

For more details on Scaler configuration, see Commands.

Note

By default, the scheduler starts with the no scaling policy, meaning no workers are provisioned automatically. To enable auto-scaling, pass --policy-content (-pc) to the scheduler.

Enabling Auto-Scaling

Configure the scheduler with a scaling policy, then start a worker manager:

# Terminal 1 — Scheduler
scaler_scheduler tcp://127.0.0.1:8516 -pc "allocate=even_load; scaling=vanilla"

# Terminal 2 — Worker Manager (e.g., Baremetal Native)
scaler_worker_manager baremetal_native tcp://127.0.0.1:8516 --max-task-concurrency 8

The vanilla policy automatically scales workers up and down based on the task-to-worker ratio. For available policies and their parameters, see Scaling Policies.

Worker Managers Overview

Worker Manager	Description	Scaling	Infrastructure
AWS HPC Batch	Runs each task as an AWS Batch job on managed EC2 compute.	Concurrency-limited	AWS Batch + S3
ORB AWS EC2	Dynamically provisions workers on AWS EC2 instances using the ORB system.	Dynamic (scheduler-driven)	AWS EC2
Symphony	Offloads tasks to IBM Spectrum Symphony via the SOAM API.	Concurrency-limited	IBM Symphony
AWS Raw ECS	Provisions full Scaler worker processes as Fargate tasks.	Dynamic (scheduler-driven)	AWS ECS Fargate
Baremetal Native	Spawns workers as local subprocesses. The simplest worker manager and the recommended starting point.	Dynamic or fixed	Local machine

Although worker managers target different infrastructures, many configuration options are shared. See Common Worker Manager Parameters for these shared settings.

Unified Entry Points

The scaler_worker_manager command provides a single entry point for all worker managers. The scaler command boots the full stack from a single TOML config file.