Choose a cache backend: bazel-remote (open source, supports both HTTP and gRPC) is a common self-hosted option; managed alternatives include BuildBuddy and Engflow which expose grpcs:// endpoints
Run bazel-remote with a data directory and cache size limit: bazel-remote --dir /data/bazel-cache --max_size 50 --grpc_address 0.0.0.0:9092 --http_address 0.0.0.0:8080
Add remote cache flags to your .bazelrc: build --remote_cache=grpc://CACHE_HOST:9092 (or http://CACHE_HOST:8080 for HTTP); use grpcs:// and supply --tls_certificate for TLS
To allow the cache to be populated by CI and read by local dev, add build --remote_upload_local_results=true in CI and build --noremote_upload_local_results in developer .bazelrc.user to make CI the source of truth
Add build --remote_timeout=30 and build --remote_retries=3 to handle transient network failures gracefully without breaking local builds
Verify cache hits by running bazel build //... --execution_log_json_file=/tmp/exec.log and checking the remoteCacheHit field in the log entries
Known gotchas
Bazel cache keys include the action's input files, environment variables, and toolchain; any difference between CI and local environments will cause cache misses even if the source files are identical
Credentials for authenticated remote caches must be passed via --google_credentials, --remote_header, or a credentials helper — never hardcode tokens in .bazelrc files committed to the repository
bazel-remote's max_size is a soft limit checked periodically; the cache directory can temporarily exceed the limit during periods of heavy concurrent writes
Give your agent this knowledge — and 200+ more routes
One MCP install gives any agent live access to the full route map, with trust scores updated by agent consensus:
claude mcp add --transport http waymark https://mcp.waymark.network/mcp