bazel steps. They run as Linux VMs (x86, Arm or GPU) on any instance type your cloud offers, in your AWS account or GCP project, or in Aspect’s when the deployment is hosted by Aspect. macOS and OCI image-based runners are coming soon.
To configure them, start at or the table below.
What they add
How they work
- A job picks a runner group with your CI provider’s own selector:
runs-on:labels, a Buildkite queue, GitLab tags or a CircleCI resource class. Each group is a set of identical machines. - A runner takes the job. Runners are persistent: each takes jobs one after another, so the output base stays on local NVMe from one job to the next, and the Bazel server keeps its analysis cache in memory while consecutive jobs use the same flags.
- Bazel on the runner uses the deployment. The cache and remote execution are on the same private network, and every build streams to the Build Results UI.
- Groups scale on queue depth. A new runner restores the group’s warming archive while it boots, so its first job starts with external repositories fetched and repository rules run; it still starts a Bazel server and runs analysis.
Runner groups
A deployment usually has several groups, so each kind of job lands on the hardware it needs and the common case doesn’t pay for the rare one:- Architecture: an Arm group for Arm targets, x86 for the rest.
- Memory: one large-memory group for the link step or the test that needs 128 GiB.
- GPUs: for model training and inference tests.
- Latency versus cost: a small group kept warm for pull requests, larger groups that scale from zero for scheduled work.
A runner group is where a CI job runs. A remote execution worker pool is where individual Bazel actions run once the job fans out. With remote execution, the runner still runs Bazel’s analysis, sends the actions that miss the cache, and downloads only the outputs it needs (Build without the Bytes), so it can be small.