Native action cache and CAS
BoringCache speaks the HTTP cache paths Bazel expects instead of turning Bazel outputs into generic archives.
Getting started
Guides
On this page
Docs / Adapter commands / Bazel
Give Bazel a shared HTTP action cache and content-addressable store without replacing Bazel's action keys or build graph.
BoringCache speaks the HTTP cache paths Bazel expects instead of turning Bazel outputs into generic archives.
Use the same cache from a developer laptop, GitHub Actions, or another CI runner.
Restore-only tokens can read remote cache while trusted jobs publish action outputs.
Keep the command and cache tag in .boringcache.toml, then use the same boringcache bazel entrypoint locally and in CI. The action cache and CAS stay Bazel-native.
[adapters.bazel] tag = "bazel-cache" command = ["bazel", "build", "//..."] # Run: boringcache bazel
The Action starts the Bazel adapter and gives the later Bazel step its remote-cache settings.
- uses: boringcache/one@f0fb9b2d926a32b10c543e92093ba00c5a291b79 # v1.33.0 with: trust-policy: auto mode: bazel - run: bazel build //...
Approve the repository through Connect CI and grant the job contents: read and id-token: write. The Action uses that Machine connection. Pull requests restore by default; trusted jobs may publish. See the authentication example in the GitHub Actions reference for scoped credentials when OIDC is unavailable.
gRPC · Bazel remote cache · BoringCache vs BuildBuddy.
28%
BoringCache finished the same-source Bazel benchmark in 260s, compared with 360s for BuildBuddy.
Open run →Check the tool's own reference when you need cache-key rules, build settings, or version-specific behavior.
Compare every supported command, protocol, and Action mode in one place.
Adapter command index →Need help or found something unclear? Open an issue or browse the CLI repo.
We use cookies to understand how people use BoringCache. Learn more