Skip to content

Demo

See what your build reused.

Choose a recorded Docker, Bazel, or Rust build. Explore its cache activity, then use the same integration in your repository.

boringcache / Build workspaces
Insights

Mastodon build cache

GitHub Actionsmainddd4bf7

Open run

Docker and compiler cache reads

0 cache errors

98.3%

113 of 115 cache reads were hits.

Hits
113
Misses
2

Cache data transferred

Restored
1.57 GB
Uploaded
90.1 KB
  • Docker 1.57 GB restored · 90.1 KB uploaded
  • sccache 246 KB restored · 0 Bytes uploaded

Cache activity by tool

  • Docker 101 hits · 2 misses
  • sccache 12 hits · 0 misses

gRPC build cache

GitHub Actionsmainafbb918

Open run

Bazel action-cache reuse

0 cache errors

100.0%

3,787 of 3,787 Bazel action-cache lookups were hits.

Action-cache hits
3,787
Action-cache misses
0

Cache data transferred

Restored
56.7 MB
Uploaded
0 Bytes
  • Bazel 56.7 MB restored · 0 Bytes uploaded

Cache activity by tool

  • Bazel 3,787 hits · 0 misses

Deno build cache

GitHub Actionsmain48b6eee

Open run

Shared cache reuse

0 cache errors

96.9%

1,837 of 1,896 remote read lookups were hits.

Remote hits
1,837
Missed lookups
59

Cache data transferred

Restored
4.68 GB
Uploaded
304 MB
  • sccache 1.2 GB restored · 84.2 MB uploaded
  • Archive 3.48 GB restored · 219 MB uploaded

Cache activity by tool

  • sccache 1,834 hits · 59 misses
  • Archive 3 hits · 0 misses

Know what to look at next.

Reuse

See which cache reads found a result and which missed.

Transfers

Inspect the data a run restored and uploaded.

Tools

Find the tool responsible for each kind of cache activity.

Inspect the same activity in your build.

Choose a tool to see its .boringcache.toml configuration and build command.

Keep your Docker build command.

Reuse image layers across compatible builds. The CLI adds shared cache to the command in your repo configuration.

Set up Docker →
.boringcache.toml
workspace = "my-org/app"

[adapters.docker]
tag = "docker-cache"
command = ["docker", "buildx", "build", "."]
Docker
boringcache docker

Reuse tasks across your monorepo.

Share Turborepo's remote cache across developers and CI jobs. Skip tasks when their inputs already have cached results.

Set up Turborepo →
.boringcache.toml
workspace = "my-org/app"

[adapters.turbo]
tag = "turbo-cache"
Turborepo
boringcache turbo -- npx turbo run build

Reuse Cargo dependencies and build results.

Run Cargo with dependency, target, and compiler caches from the same workspace.

Set up Cargo →
.boringcache.toml
workspace = "my-org/app"

[adapters.cargo]
tag = "rust-build"

[adapters.sccache]
tag = "rust-compiler"
Cargo
boringcache cargo -- build --release

Reuse matching compiler results.

Connect sccache to your workspace with the CLI. Keep using your existing build and test commands.

Set up sccache →
.boringcache.toml
workspace = "my-org/app"

[adapters.sccache]
tag = "rust-compiler"
sccache
boringcache sccache -- cargo test

Share Bazel action results.

Use Bazel's native remote cache to reuse completed build work across your team.

Set up Bazel →
.boringcache.toml
workspace = "my-org/app"

[adapters.bazel]
tag = "bazel-cache"
Bazel
boringcache bazel -- bazel build //...

Reuse completed Gradle tasks.

Connect Gradle's build cache to your workspace. Reuse matching task outputs on the next runner or developer machine.

Set up Gradle →
.boringcache.toml
workspace = "my-org/app"

[adapters.gradle]
tag = "gradle-cache"
Gradle
boringcache gradle -- ./gradlew build --build-cache
Explore all supported tools →

Use the same cache wherever you build.

Commit .boringcache.toml once. Your CI jobs and local worktrees read the same workspace and tool definitions.

Use cache from earlier builds.

Run your configured Docker build locally. Compatible builds can reuse cache published by CI or another developer.

Local build
boringcache docker

Reuse cache in a new worktree.

Your committed configuration goes with the checkout. Build Docker images with shared cache while keeping the worktree's files separate.

Git worktree
git worktree add ../app-review -b review
cd ../app-review
boringcache docker

Run the same Docker build in Actions.

Add the Action after checkout. It reads your repo configuration and uses the workspace connection approved for your repository.

Set up GitHub Actions →
GitHub Actions
permissions:
  contents: read
  id-token: write

steps:
  - uses: boringcache/one@f0fb9b2d926a32b10c543e92093ba00c5a291b79 # v1.33.0
    with:
      mode: docker
      trust-policy: auto

Use your workspace from Buildkite.

With the CLI installed on your runner, run the Docker adapter through your approved Buildkite OIDC connection.

Set up Buildkite →
Buildkite
steps:
  - label: Build
    command: >
      boringcache ci run
      --oidc-provider buildkite
      -- boringcache docker

Use shared cache in GitLab CI.

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 →
GitLab CI
build:
  timeout: 1h
  id_tokens:
    BORINGCACHE_OIDC_TOKEN:
      aud: urn:boringcache:workload
  script:
    - boringcache ci run --oidc-provider gitlab -- boringcache docker

Connect CI with OIDC. Control who can publish.

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

  • Trusted jobs publish Give trusted workflows permission to publish new cache. Keep access scoped to the workspace they need. Read + publish
  • Pull requests read Let pull requests reuse published cache without replacing the cache other builds depend on. Read only

Try it on a build you know.

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.