Run your tests and builds on the machines you already own.
Enrol a workstation, a VPS, a friend's box. Submit from any project and the work lands wherever there is room.
Submit from any working directory. The tree is packed, shipped and run on a pool machine, and the output streams back as it happens. The command's exit code is yours.
$ falllow run -- pytest -q
sending workspace (12 files, 1 new)
placed on ryzen-9900x · 8 threads reserved
........................................
40 passed in 6.21sOne submission becomes several independent jobs, each told its slice through FALLLOW_SHARD_INDEX. They land on whichever machines are free and
reduce to one exit code.
$ falllow run --shard 4 -- pytest -q
4 shards
shard 1/4 10 passed in 2.03s
shard 2/4 10 passed in 1.94s
shard 3/4 10 passed in 2.11s
shard 4/4 10 passed in 1.88s
all 4 shards succeededRedeem a token from the manager and the machine joins with its real inventory (cores, memory, GPUs) and a budget that leaves its owner room to work.
$ falllow-runnerd enroll \
--server https://app.falllow.com \
--token flw_e_… --label cuda-12
enrolled as nuc-01 · 8 threads, 32 GB budgetedA runner dials the control plane and keeps the connection open. Nothing listens on the machine, so a laptop behind CGNAT joins the pool the same way a server does.
Each job gets a fresh tree, hard-linked from a content-addressed store. Only the files that changed cross the network.
Threads and memory are reserved per job and enforced by the kernel: cgroups on Linux, job objects on Windows. A runaway job cannot take the machine with it.
A failing test exits with the test runner's own code. Only falllow's own failures use 170, and only those are ever retried.
Point a repository at the control plane and a queued workflow job gets an ephemeral runner from the pool. falllow does not reimplement GitHub's runner protocol; it starts the official runner with a just-in-time registration and takes it down again after one job.
How the bridge works