productbuild & ship
rbs job submit --gpus 2 -- rbs run //ml/train:job
Your laptop is a thin client. The branch is the machine.
Every branch runs on a server in your cloud, so the heavy work never happens on a laptop. When one machine is not enough, builds fan out and GPU jobs queue on a real scheduler.
how you use it
Remote execution, in order.
01
Open a branch: the machine is already there
The branch server is the executor. Builds, tests and the services you run live on it; your teammates open the same server. A first-week engineer gets the same build times as everyone else, on any laptop.
02
The agent’s loop: a server per agent
Every agent run gets a branch server of its own, so ten agents on ten tasks are ten machines, not ten processes fighting over yours. Their builds and tests run there, and their jobs queue under the same fair share as everyone else’s.
03
Fan out when one machine is not enough
A build with remote execution sends its actions to the workspace’s workers; identical actions in flight are deduplicated onto one run, and a worker that disappears cannot clobber a reassignment with a late result. An action that reads a secret is refused remotely rather than shipped in the clear.
04
GPU work queues like on an HPC cluster
Submit training runs with CPUs, memory, GPUs, a time limit, array tasks, dependencies and containers. Hierarchical fair share, the algorithm Slurm uses, keeps one team from starving another. Inputs and outputs travel through the content store, and CI can run on the same cluster with one flag.
not built yet: hosted cluster capacity per cloud; today a workspace attaches its own workers · Bazel remote execution against the cluster
The full reference lives in the docs.
works with
Open a branch and try it.
Boots in seconds. Your team joins with a link.