Blog
What I have learned about repeated build work, the approaches that helped, and the ones I stopped using.
RSS feedWhen BuildKit has to run a step again, portable cache mounts and native tool caches can preserve cached directories and tool results for reuse inside that step.
I thought Rust build cache meant the target directory. Building the BoringCache CLI taught me why dependency state, Cargo target state, and sccache solve different parts of the build.
I build Rails with Dagger, reuse the slow work with BoringCache, then send one filesystem artifact to four Ubuntu servers.
Why I chose shared cache and object storage instead of larger runners, and what that choice looks like on PostHog and a 40 GB Rust target.
After a year of building it, I am introducing BoringCache: shared cache, build outputs and container images wherever the build runs.
How I use content-defined chunks and client optimizations to save and restore large Cargo targets, and what I am doing about accumulated build outputs.
I tried moving BuildKit state between ephemeral runners. Restoring it was fast, but changed builds were slower than the simpler cache backend.
A Docker build could finish its build steps and then spend minutes exporting cache. I wanted to prepare the cache while those steps were running.
I started with a slow Ruby install on an old MacBook Air. I wanted to reuse work that another machine had already done, wherever I chose to build.
The practical guides cover setup choices, slow exports, and missing cache.
We use cookies to understand how people use BoringCache. Learn more