Stop shipping your cache across the network
Persistent Docker layer caching
Keep the BuildKit layer cache warm between jobs without exporting to a registry or to the Actions cache.
Nothing to export
The cache lives on the builder. No cache-from, no cache-to, no registry round-trip.
Shared across jobs
Matrix legs and separate workflows attach to the same warm cache.
Native per-arch
amd64 and arm64 builders each keep their own cache on their own hardware.
The standard advice is to export your layer cache to a registry with cache-to and pull it back with cache-from. It works, but for a large image the transfer often costs more time than the layers save.
A persistent builder removes the transfer. The cache never leaves the machine that produced it.
| Approach | Cache transfer | Typical rebuild |
|---|---|---|
| No cache | None | Full build every time |
| registry cache-from/to | Both directions, every job | Fast build, slow transfer |
| Actions cache | Both directions, capped at 10 GB | Frequent misses |
| Persistent builder | None | Only changed layers |
Common questions
- Do I still need cache-from and cache-to?
- No — delete them. The builder holds the cache on its own disk, so those flags only add an export and import round-trip that costs more than it saves on large images.
- How long does the layer cache survive?
- It persists between jobs and across branches for 14 days by default, configurable per organisation. It is not scoped to a branch, which is why pull requests start warm.
- What invalidates the whole cache?
- A base image change. Every layer after FROM depends on the base digest, so pin by digest and update deliberately rather than at random.
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.