How to Enable Remote Caching in Bazel and Cut Build Times

Speed up your Bazel builds by enabling remote caching. Follow this practical guide to set up a cache server, configure your workspace, verify cache hits, and understand the trade‑offs. Reduce build times and network traffic with confidence.

What’s the problem?

In large monorepos, a single Bazel build can take minutes or even hours. Even when you only touch a handful of files, Bazel still rebuilds every target that depends on them. That overhead is expensive on CI agents, on developer laptops, and in a distributed team where multiple people rebuild the same code.

Why remote caching helps

Remote caching stores the binary outputs of a build step on a shared server. Subsequent builds that need the same output can fetch it instead of recomputing it. The result is a dramatic drop in build time, reduced network traffic, and a more consistent build experience across machines.

How to enable it in a real project

Choose a cache backend. Bazel supports several back‑ends out of the box: a simple HTTP server, Google Cloud Storage, Amazon S3, or a custom cache service like Bazel's remote cache. For this example we’ll use a local HTTP cache running on localhost:8080.

Start a basic cache server (e.g., bazel-remote from the Bazel team):
```
bazel-remote --port=8080
```

Configure your workspace. Add a bazelrc entry that points Bazel to the cache server and enables authentication if needed:

# .bazelrc
build --remote_cache=http://localhost:8080
build --remote_default_exec_properties=repo_cache=true
# Optional: secure transport
build --experimental_remote_instance_name=repo_cache

Replace localhost:8080 with your production cache URL.

Build once to populate the cache. Run a target that produces a new artifact:
```
bazel build //app:hello_world
```
Check the console for a line like Uploading to cache – that means the artifact was stored.
Verify cache hits. Re‑run the same target and look for Cache hit in the output. Enable verbose logging to see the exact URLs:
```
bazel build //app:hello_world --experimental_remote_log=remote.log
```
Open remote.log and confirm a GET request to the cache server.

Measure the difference. Time the first and second runs:

time bazel build //app:hello_world
# First run: ~30s
# Second run: ~5s (cache hit)

Trade‑offs and limitations

Cache size and eviction. A growing cache can fill disk space. Configure an eviction policy (e.g., LRU) or set a retention period.
Stale artifacts. Bazel uses a hash of source files, toolchain, and environment variables. If any of these change, a cache miss occurs. Keep toolchain versions consistent across agents.
Security. Exposing raw build artifacts can leak sensitive data. Use HTTPS, authentication tokens, or signed artifacts in production.
Network latency. If the cache server is far away, downloads can become the bottleneck. Place the server close to your CI infrastructure.

When to use remote caching

Remote caching shines when:

Your repository is large and rebuilds are expensive.
Multiple developers or CI agents run the same targets.
Build times are a bottleneck in your workflow.

It’s less useful for small, one‑off builds or when you’re only iterating on a single file in a tiny repo.

Takeaway

Enabling remote caching in Bazel is a low‑cost, high‑impact step. By pointing --remote_cache to a shared server and ensuring consistent toolchains, you can cut build times from minutes to seconds and free up CI resources. Just monitor hit ratios, secure the server, and keep an eye on cache size to avoid new bottlenecks.

Speeding Up Bazel Builds with Remote Caching: A Practical Guide