Skip to main content

​
Overview

Blacksmith transparently caches your Bazel build artifacts across jobs in a repository, with zero code changes required. There are no .bazelrc changes to make, no workflow configuration to set up, and no need for a third-party remote cache provider like EngFlow or BuildBuddy.

​
What Bazel build caching speeds up

Bazel breaks a build into individual actions. When an action’s inputs have not changed, Blacksmith returns its saved outputs instead of making Bazel run it again. This can skip expensive work such as:
  • Compiling source files
  • Running cacheable tests
  • Generating code
  • Linking and packaging binaries
The first build fills the cache, and later builds reuse everything that is still valid. Changes to source files, build flags, or toolchains will miss, as expected.

​
Enable Bazel build caching

An organization admin can enable Bazel build caching from Settings > Features in the Blacksmith dashboard. Find Bazel Build Caching under Caching.

​
Existing remote cache setups

You don’t need to change your workflow or .bazelrc, since Blacksmith configures Bazel before the job starts. The exception is an explicit remote cache: if your .bazelrc or workflow sets its own --remote_cache (for example, a remote caching solution like EngFlow or BuildBuddy), that configuration takes precedence, so remove its --remote_cache settings and credentials for Blacksmith’s cache to take effect. Blacksmith replaces remote caching, not remote execution, so if you also rely on a provider for remote execution, contact us through the Blacksmith support portal first.

​
Caching across branches

Each repository has its own Bazel cache. Unlike the Actions cache, Bazel cache entries do not use branch-protection boundaries. Matching build artifacts are shared across branches and pull requests within that repository, so a build on main can warm the cache for a later pull request. Bazel only reuses an artifact when its action key matches. Caches are also separated by CPU architecture.

​
Storage limits and deletion

Each repository cache has a storage cap, shown alongside current usage on the Cache page. When a cache grows past its cap, Blacksmith evicts the least recently used action results and their artifacts. If your working set regularly exceeds the cap, builds will see more cache misses. You can clear a repository’s cache from the Cache page at any time, and the next Bazel job starts fresh. Disabling Bazel build caching deletes the existing cache.

​
Measure the impact

Open the Cache page, choose a repository, then open the Bazel tab to see cache hit rate, build duration, storage usage, and recent jobs using the cache. The first few builds generally populate the cache, so look at how hit rate and build duration change across later runs. Hit rate shows how often Bazel reused previous work; build duration shows whether those hits made the workflow meaningfully faster. Bazel also reports remote cache hits in the process summary at the end of each build:
Here, Bazel reused three action outputs and ran four actions locally. See Bazel’s guide to checking remote cache hits for deeper troubleshooting.