Skip to main content
A local Bazel build is limited by the number of CPU cores on the machine running it. Remote Build Execution (RBE) removes that ceiling: Bazel distributes individual actions across a pool of remote workers via --remote_executor, so hundreds of compile and test actions run in parallel regardless of local hardware. Every Workflows deployment includes an optional remote execution cluster that implements the Bazel Remote Execution Protocol v2. The cluster is highly configurable: you define one or more executors, each pinned to a specific container image (and optionally a custom Bazel platform), and each executor backed by one or more worker pools with their own instance type (including GPU instance types), CPU/memory shape, network access toggle, max concurrency, and auto-scaling policy (minimum, warm, and maximum pool sizes; target-tracking scaling; and schedule-based rules to pre-scale ahead of known peaks). This means you can size each executor to exactly the workload it handles, mix architectures (amd64, arm64) and toolchain images within a single deployment, and scale down to zero when the queue is empty so you pay nothing for idle capacity.

​
What RBE gives you

Action-level parallelism. Bazel’s action graph is already a DAG. With RBE, every action that has no unmet dependencies runs immediately on the worker pool, not queued behind other actions on a single machine. Multiple platforms, your hardware. Define several RBE platforms side by side, the same way you define runner groups: each pinned to its own container image and instance type, so you control architecture, CPU, memory, NVMe, and GPUs per platform. Docker-based tests are fully supported on workers. Right-sized actions. Each platform supports multiple worker size classes, and actions are matched to a size class and memory automatically, so heavyweight link and test actions land on big machines without reserving them for every small compile. Per-action platform constraints. Each action can declare the execution platform it needs. You can mix container images, OS versions, and toolchains within a single build without splitting it into separate jobs. Cross-platform builds. The worker pool supports arm64 and amd64 simultaneously. Cross-compilation, multi-arch container publishing, and other cross-platform workflows run as native builds on the right architecture rather than through emulation. Cost-proportional resource allocation. Provision large workers for link steps and test shards that need memory; use smaller workers for cheap compile actions. Workers scale down when the queue is empty, so you pay only for what you use.

​
Standard protocol, no lock-in

The execution cluster implements the Bazel Remote Execution Protocol v2. Any REv2-compatible client works with it, and nothing about your build depends on RBE to keep working.

​
Adopt at your own pace

RBE is in every Workflows deployment from day one for when you’re ready for it. Most teams start with the warm CI runners and remote cache, which deliver most of the speedup with no migration; turning RBE on later is a configuration change on the same deployment, tuned by Aspect engineers under our SLA.