Workers

By default every step runs in the server’s own process. When a step needs another machine (Windows, a GPU, a box with devin logged in), a worker runs it there.

wfx workers              # machines in the pool, and the line that adds another
wfx workers rm <id>      # forget a machine
wfx workers rotate       # new join token; machines already joined keep working

wfx workers prints the join line. On the other machine:

wfx-runner join --url https://wfx.example.com --token wfx_… --labels windows,devin
wfx-runner run

The runner is outbound only. It connects to the server and asks for work, so no inbound port needs to be opened on the worker. A step goes to a matching worker when its runs-on (or the workflow’s) names a label:

steps:
  - id: build-windows
    runs-on: windows
    run: ./build.ps1
    shell: pwsh

The server side is the /api/workers endpoints: join, claim, heartbeat and job events.

Tools and config on a worker

Each worker restores its own tools, config files and env defaults from a bucket through carry, so adding jq to one machine is carry tool add, not an image rebuild. See Tools and config with carry.

Steps that must not overlap

A worker pool runs steps in parallel. When two runs of the same workflow must not overlap (a migration, a nightly job), give the workflow a concurrency: group.