Speed up your Bazel builds with Namespace
Remote caching and remote execution for Bazel, on Namespace compute and storage. Reuse action results across CI, local, and Devbox builds, and run the actions themselves on workers that Namespace keeps running, so a build does not wait for capacity to come up.
Why Namespace for Bazel?
Getting Started
Configure access
Generate a bazelrc that points Bazel at Namespace. Start with the cache, and add
remote execution when you want the actions to run on Namespace compute too.
$nsc bazel setup --remote=false --bazelrc=~/.namespace.bazelrc
This command provisions a remote Bazel cache, if needed, and writes a bazelrc with the relevant configuration options.
Run Bazel
$bazel --bazelrc=~/.namespace.bazelrc build //...
You can pass multiple --bazelrc flags if you need to combine Namespace's generated
configuration with your existing project configuration. Bazel reads the files in the
order it is given them, and where two files set the same option, the last one read
wins. See bazelrc files for the full order, which
also covers the workspace and home rc files Bazel picks up on its own.
Caching and Remote Execution
The Bazel cache shares action results across invocations and machines. It applies to any action Bazel can cache, and the saving is largest where compilation is slow, such as Rust and C++ codebases. The cache is shared, so CI and local builds reuse each other's results.
Remote Execution runs the actions themselves on Namespace compute, scaling a build across many workers for high parallelism. Its workers keep low-latency access to the cache, so remotely executed actions read and write the same artifacts as everything else. Actions can also be routed to workers on a different platform than the machine running Bazel, which is how a Linux host can drive a macOS build.