Skip to main content

Remote build execution for Bazel

Remote execution of a Bazel build allows you to distribute build and test actions across multiple machines. This speeds up build and test execution, allows reuse of build outputs across development teams, and provides a consistent environment.

You can use the Bitrise Build Cache with remote build execution both on Bitrise and in a non-Bitrise CI environment.

Configuring remote build execution on BitriseClick to copy link

  1. Set up the Bitrise Build Cache for Bazel: Configuring the build cache for Bazel in the Bitrise CI environment.
  2. Log in to Bitrise and select Bitrise CI on the left, then select your project.
  3. Click the Workflows button on the main page.
  4. In the Bitrise Build Cache for Bazel Step, set the Enable Bazel RBE input field to true.

Configuring remote build execution in a non-Bitrise environmentClick to copy link

  1. Start setting up the Bitrise Build Cache for Bazel: Configuring the build cache for Bazel in other CI environments.

  2. When enabling the Bitrise Build Cache, add the --rbe flag.

    /tmp/bin/bitrise-build-cache activate bazel --cache --cache-push=false --rbe
    Cache

    We recommend setting the --cache-push flag to false because during remote build execution, workers upload results to the cache.

Bazel offers a number of command flags that are needed to get the most out of remote build execution.

Flag and recommend valuesDescription
--jobs=100Defines the maximum number of build/test actions Bazel may have "in flight" at once. If you omit the flag Bazel silently falls back to the number of logical CPU cores on the host VM. That default is appropriate for local execution but severely under‑utilises the RBE cluster. --jobs=100 is a good starting point for most Android/iOS monorepos but it can be increased gradually based on the worker count.
MacOS: --remote_default_exec_properties=Arch=arm64 --remote_default_exec_properties=OSFamily=Darwin Linux: --remote_default_exec_properties=Arch=amd64 --remote_default_exec_properties=OSFamily=LinuxDefines the default execution platform (worker pool). Supply key‑value pairs such as Arch=arm64 or OSFamily=Darwin. Multiple occurrences are merged. Make sure that no other exec_properties are set anywhere for the targets, otherwise Bazel will not match the worker pool and the build will fail.
--spawn_strategy=remote,localDetermines the order in which Bazel tries to execute an action. Bazel will use the first strategy in the list that can run a given action. The default value is remote,worker,sandboxed,local. Keep remote first so actions run in your remote execution environment, with a graceful fallback to local execution.
--noremote_upload_local_resultsSkips re‑uploading outputs that were produced locally. Remote workers already push artifacts to the cache, saving bandwidth. This config flag is also configured via Bitrise Build Cache CLI. If you use it, please make sure that --cache-push flag is false or off in the CLI when you use this flag.

We recommend adding these flags to your .bazelrc file and reuse:

MacOS:

build:remote --jobs=100
build:remote --noremote_upload_local_results
build:remote --spawn_strategy=remote,local
build:remote --remote_default_exec_properties=Arch=arm64
build:remote --remote_default_exec_properties=OSFamily=Darwin

Linux:

build:remote --jobs=100
build:remote --noremote_upload_local_results
build:remote --spawn_strategy=remote,local
build:remote --remote_default_exec_properties=Arch=amd64
build:remote --remote_default_exec_properties=OSFamily=Linux

With everything in place, you can invoke remote build execution by adding the remote config to any Bazel command:

bazel build //... --config=remote