Make better use of the machines you already have.
I built BoringCache because useful build work was being repeated on machines that could have shared it.
Gaurav Tiwari
GitHubIt started with a Ruby compile that took too long.
In July 2025, I was installing Ruby on an old MacBook Air with 16 GB of RAM while working on a side project. Compiling it took longer than I wanted. I wondered whether I could reuse one of the Ruby builds already available for GitHub Actions, but those builds depended on their installation paths and environment.
I started experimenting with precompiled Ruby builds, then used Dagger to build a pipeline and cache its steps. The problem I wanted to solve became broader: useful build results existed, but sharing them outside the machine or provider that produced them was difficult.
From 2025 to 2026, I benchmarked GitHub Actions caching and other remote caches across a range of build tools. I launched the first iteration of BoringCache in July 2026.
Reuse completed work before adding more compute.
Building software is interesting. Understanding a problem and writing code to solve it are worth spending time on. Watching CI download the same dependencies or compile something another machine already built is not. That is the boring part, and that is where the name came from.
I wanted to make better use of existing machines, avoid repeated computation and store fewer copies of the same data. Bigger machines help, but I kept coming back to a different question: why ask another machine to do the same work again? A faster runner can repeat work faster. A shared cache can avoid repeating it. Being careful with compute, storage and developers' time was a main reason for building BoringCache, and it still guides what I work on.
How people save and use the cache matters to me too. GitHub Actions' save-and-restore model and the custom S3 scripts I had seen teams use influenced the design. I wanted saving a file or directory and restoring it where it was needed to be simple and fast, with clear names and few steps. Keeping storage affordable and reducing the time spent saving and retrieving cache are part of that same goal.
I chose to keep cache independent from compute so teams could reuse compatible work across the machines and providers they already use. That means putting more engineering into efficient storage and transfer, but it avoids making a particular runner fleet part of the cache model.
Try it with your own build.
Get started with 30 GB of free cache. No credit card required.
Developed by BoringTech Ltd in London, United Kingdom. I write about build problems, experiments, and product decisions as I work through them.