The 10 GB limit, removed
Unlimited GitHub Actions cache
A drop-in replacement for actions/cache with no 10 GB repository cap, 1 GB/s restore and cross-workflow sharing.
No size cap
Cache what you need. Eviction is org-wide and least-recently-used, not a hard per-repo ceiling.
1 GB/s restore
Large caches restore in seconds instead of minutes.
Cross-workflow
A cache written by your build workflow is readable by your test and release workflows.
Analytics
Hit rate, restore time and size per key, so you can see which cache is actually earning its keep.
GitHub caps Actions cache at 10 GB per repository and evicts least-recently-used entries once you cross it. On a monorepo with several toolchains you blow through that in a week, and from then on every run is a cache miss that nobody notices.
runnerhut cache keeps the same API. You do not change your workflow — actions/cache is transparently redirected when a job runs on a runnerhut runner.
- uses: actions/cache@v4 with: path: ~/.npm key: ${{ runner.os }}-node-${{ hashFiles('**/package-lock.json') }}Common questions
- Do I need to change my actions/cache configuration?
- No. actions/cache is transparently redirected when the job runs on a runnerhut runner. The same keys and restore-keys work.
- Is there really no size limit?
- There is no per-repository cap. Eviction is organisation-wide and least-recently-used, so a large cache displaces stale entries rather than hitting a ceiling at 10 GB.
- Can two repositories share a cache?
- Cache is scoped per repository by default with cryptographic isolation. Cross-repository sharing is available per organisation for monorepo-adjacent setups where it is deliberate.
Your next build could be twice as fast, at half the price
Start free. Migrating away is the same one line, and we publish that diff too.