Skip to content
BoringCache

Cache

Shared Build Cache

Make completed build work available to the next machine. Reuse native tool results and directory caches across CI and local development without changing runner providers.

Choose your tool Explore the demo
Shared build cache One workspace

Completed build work

  • Compiler results
  • Dependencies and task outputs
  • Docker layers

Hosted CI

Self-hosted

Local builds

Choose the tool you already use.

Connect a native cache or save a directory. Keep the build system that decides what can be reused.

Docker

Layers, cache mounts, and compiler results

Cargo / Rust

Dependencies, target state, and sccache

Bazel

Action results and build outputs

Gradle

Cacheable task outputs

Maven

Build Cache Extension results

Nx

Task results for your monorepo

Turborepo

Shared task outputs

ccache

C and C++ compiler results

sccache

Rust and C/C++ compiler results

Go

Build and cacheable test results

Nix

Completed store paths and closures

Xcode

Native compilation cache for macOS
Cache a directory See adapter commands

Upload the changes. Keep less duplicated data.

Matching cache content is stored once within a workspace. Related builds can reuse existing data instead of uploading and storing another full copy.

70–94%

Less cache stored

Across six project comparisons with actions/cache.

One workspace

Cache entry 1

A B C

Cache entry 2

A B D
Stored chunks
A B C D

Shared cache. Fast reads on the build machine.

Local serving and preloading help supported tools read cached results with less waiting. Data missing locally is fetched from the workspace.

Bring reusable state to fresh runners and keep local data between builds on persistent machines.

Inspect reuse and transfers →

5 ms

Average sccache read hit

Through BoringCache’s local cache service.

On the build machine

Your build tools

Native cache integrations

BoringCache CLI

Local hit → serve cached data

Fetch data missing locally

Shared workspace cache

Docker build cache

A changed Docker layer need not mean a cold build.

Share layers, then add package and compiler caches for work inside instructions that have to run again.

Explore Docker caching →

Docker layers

Reuse an unchanged instruction's output.

Compiler and tool caches

Reuse matching results when an instruction runs again.

Persistent cache mounts

Keep package downloads and build directories between runs.

2.9×

Faster Docker builds

Compiler and package caches in Mastodon Docker builds.

Choose who can contribute to shared cache.

Reuse does not have to mean giving every job write access. Keep access scoped to the workspaces each job needs.

Explore security →

Separate readers and publishers

  • Trusted CI jobs Publish shared cache for the next build Read + publish
  • Pull requests Reuse cache without replacing it Read only
  • Sandboxes and agents Reuse cache and keep new outputs local Read only

Connect supported CI through OIDC instead of keeping a reusable BoringCache secret in your workflow.

Try the next build with shared cache.

Start with one tool in one repository. 30 GB of cache on the Free plan. No credit card required.

curl -sSL https://install.boringcache.com/install.sh | sh
cd your-project
boringcache onboard
Configure Cache See the product