Skip to main content
Every action Bazel runs, a compile, a link, a test, is keyed by a hash of its inputs, its command line and its environment. Bazel keeps the result against that key, so an action it has run before comes back from cache instead of running again. By default, Bazel caches action results on your local machine. A remote cache moves that cache off the machine and shares it, so a result one machine computed is a cache hit on every other, including a fresh CI checkout.

​
How it works

Before running an action, Bazel asks the remote cache whether that key already has a result. On a hit, it fetches the outputs and moves on. On a miss, it runs the action and uploads the result, so the next build that needs it gets a hit.

​
Where it’s available

The remote cache is available on Aspect Cloud and Aspect Enterprise. Who shares a cache:
  • Aspect Cloud: CI and developer machines use the same cache.
  • Aspect Enterprise: the cache sits on the same private network as the runners and workers, so CI reads and writes never cross the internet. Developer machines and CI you run yourself reach the deployment through its external endpoint, or privately over VPC peering. The external endpoint can share CI’s cache, so a laptop gets CI’s hits, or have storage of its own to keep developer traffic apart; that’s a configuration choice for the deployment.

​
Who writes to the cache

On Aspect Cloud, and on an Aspect Enterprise deployment whose external endpoint shares CI’s cache, developer machines and CI write to the same cache. For CI-only writes, set Bazel’s --noremote_upload_local_results on developer machines, so a laptop reads CI’s results without uploading its own. Put it in each developer’s ~/.bazelrc, which both vanilla bazel and Aspect CLI tasks read on a developer machine:
~/.bazelrc

​
Configuring your repository

The cache is a set of Bazel flags; your build rules don’t change.
  • Aspect CLI tasks take --remote, and on CI they connect to the cache without it.
  • Vanilla bazel reads the flags from the rc that aspect setup bazelrc writes, on a developer machine or in the CI setup step.

​
Build without the Bytes

Bazel 7 and later default to --remote_download_toplevel: Bazel downloads the outputs of the targets you asked for and leaves intermediate outputs in the cache. On CI, --remote_download_minimal downloads less: only what local actions need. Keep it off developer builds, where you want outputs on disk, by setting it under build:ci and running CI builds with --config=ci:
.bazelrc

​
Seeing what it does

Every build that streams to the Build Results UI shows how many actions hit the cache and how many ran. Compare puts the cache hits of two invocations side by side and flags the likely cause when one misses where the other hit.

​
Standard protocol

The cache implements the Remote Execution API (REAPI) v2 over gRPC. Any build system that speaks it can use the cache, including:
  • Bazel
  • Buck2
  • Pants
  • reclient, used by Chromium and Android