Reuse
See which cache reads found a result and which missed.
Demo
Choose a recorded Docker, Bazel, or Rust build. Explore its cache activity, then use the same integration in your repository.
GitHub Actionsmainddd4bf7
98.3%
113 of 115 cache reads were hits.
GitHub Actionsmainafbb918
100.0%
3,787 of 3,787 Bazel action-cache lookups were hits.
GitHub Actionsmain48b6eee
96.9%
1,837 of 1,896 remote read lookups were hits.
See which cache reads found a result and which missed.
Inspect the data a run restored and uploaded.
Find the tool responsible for each kind of cache activity.
Choose a tool to see its .boringcache.toml configuration and build command.
Reuse image layers across compatible builds. The CLI adds shared cache to the command in your repo configuration.
Set up Docker →workspace = "my-org/app" [adapters.docker] tag = "docker-cache" command = ["docker", "buildx", "build", "."]
boringcache docker
Share Turborepo's remote cache across developers and CI jobs. Skip tasks when their inputs already have cached results.
Set up Turborepo →workspace = "my-org/app" [adapters.turbo] tag = "turbo-cache"
boringcache turbo -- npx turbo run build
Run Cargo with dependency, target, and compiler caches from the same workspace.
Set up Cargo →workspace = "my-org/app" [adapters.cargo] tag = "rust-build" [adapters.sccache] tag = "rust-compiler"
boringcache cargo -- build --release
Connect sccache to your workspace with the CLI. Keep using your existing build and test commands.
Set up sccache →workspace = "my-org/app" [adapters.sccache] tag = "rust-compiler"
boringcache sccache -- cargo test
Use Bazel's native remote cache to reuse completed build work across your team.
Set up Bazel →workspace = "my-org/app" [adapters.bazel] tag = "bazel-cache"
boringcache bazel -- bazel build //...
Connect Gradle's build cache to your workspace. Reuse matching task outputs on the next runner or developer machine.
Set up Gradle →workspace = "my-org/app" [adapters.gradle] tag = "gradle-cache"
boringcache gradle -- ./gradlew build --build-cache
Commit .boringcache.toml once. Your CI jobs and local worktrees read the same workspace and tool definitions.
Run your configured Docker build locally. Compatible builds can reuse cache published by CI or another developer.
boringcache docker
Your committed configuration goes with the checkout. Build Docker images with shared cache while keeping the worktree's files separate.
git worktree add ../app-review -b review cd ../app-review boringcache docker
Add the Action after checkout. It reads your repo configuration and uses the workspace connection approved for your repository.
Set up GitHub Actions →permissions: contents: read id-token: write steps: - uses: boringcache/one@f0fb9b2d926a32b10c543e92093ba00c5a291b79 # v1.33.0 with: mode: docker trust-policy: auto
With the CLI installed on your runner, run the Docker adapter through your approved Buildkite OIDC connection.
Set up Buildkite →steps: - label: Build command: > boringcache ci run --oidc-provider buildkite -- boringcache docker
With the CLI installed, connect your job through GitLab OIDC and run the same Docker command. Your approved workspace connection controls access.
Set up GitLab CI →build: timeout: 1h id_tokens: BORINGCACHE_OIDC_TOKEN: aud: urn:boringcache:workload script: - boringcache ci run --oidc-provider gitlab -- boringcache docker
Approve the connection between your repository and workspace. CI jobs use workload identity to connect without a stored BoringCache secret.
Connect your CI →Separate readers and publishers
Connect one repository and inspect its first run.
curl -sSL https://install.boringcache.com/install.sh | sh cd your-project boringcache onboard
30 GB of cache free. No credit card required.
We use cookies to understand how people use BoringCache. Learn more