Skip to content

CONCEPT Cited by 1 source

Remote Build Execution (RBE)

Definition

Remote Build Execution (RBE) distributes build/test actions across a cluster of worker machines managed by a central build service. The client (e.g. Bazel) uploads action inputs to a content-addressable store (CAS), dispatches action requests, and downloads outputs; workers fetch inputs locally, run in sandboxes, and store outputs back in CAS.

Documented at bazel.build/remote/rbe; same wire protocol as bazel-remote for the cache layer.

Why it wins

From the Canva post:

Bazel can distribute its workload across a large cluster of executors. That way:

  • Build actions from CI (and developer machines) are sent to a centralized build service, allowing us to distribute build computation across a farm of machines optimized to their workloads.
  • Build inputs and outputs are co-located with build workers, allowing for faster I/O.
  • We get better sandboxing and isolation (docker containers), allowing for a higher cache hit rate.

The co-location point is key: RBE workers share a local CAS, so input artifacts fetched by one worker are available to others at local-disk speed. CI agents without RBE each re-download artifacts over the network.

Preconditions

RBE only works if actions are truly concepts/hermetic-build. Any hidden input — a local /etc file, a daemon running on the client, an environment variable — that differs on the worker causes nondeterminism or straight failures. This is why Canva's post lists RBE-compatibility as one of the Bazel migration tax-items:

[Bazel] is hard to make "Remote Build Execution" (RBE) compatible because it requires the worker pool to provide the same inputs to the actions as local execution would (that is, be truly hermetic).

Canva's partial rollout

Canva enabled RBE on a subset of CI jobs and measured:

  • Typescript builds: 200% faster
  • BE unit tests: 25% faster
  • BE compile and pack: same speed, cost down from $0.262 → $0.21/build (cheaper workers, same wall-clock).

Not rolled out fleet-wide because the hermeticity work is per-rule and incremental.

RBE vs local execution

Local (Bazel w/ remote cache) RBE
Where actions run CI worker RBE worker pool
Cache lookup Same CAS Same CAS
I/O profile Download artifacts from cache Workers share local CAS disks
Hermeticity requirement Medium (sandbox) Strict
Worker shape Same as CI agent Can be workload-optimized

The "workload-optimized worker" point justifies different pools for, e.g., I/O-heavy backend compiles vs CPU-heavy JS minification.

Seen in

Last updated · 200 distilled / 1,178 read