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, CPU/memory shape, network access toggle, max concurrency, and autoscaling 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.

​
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. 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.