How do I keep Docker layers between GitHub Actions runs?
Add docker/setup-buildx-action, then build with docker/build-push-action and set cache-from: type=gha and cache-to: type=gha,mode=max. BuildKit then saves every layer to the GitHub Actions cache and restores each unchanged layer on the next run instead of rebuilding it; use mode=max for multi-stage builds, and a scope per image when one workflow builds several. On Sengi the same lines are served from Sengi’s own cache, included, on AMD Ryzen 9 7950X3D bare metal boosting past 5 GHz: a warm build went from 68 s to 36 s, and the runner itself builds Docker images 1.9× faster than GitHub’s.
Last checked October 23, 2026, against GitHub’s Actions cache limits and billing documentation. Build times measured on Sengi September 30 and October 9, 2026.
The same YAML works on GitHub’s ubuntu-latest. The first run fills the cache; later runs show CACHED for every layer whose inputs have not changed.
Which Docker cache backend should I use?
Backend
Where layers are stored
Best for
type=gha
The GitHub Actions cache
Most repositories: no credentials, two lines of YAML
type=registry
A cache image in your container registry
A cache shared across repositories, or bigger than the Actions cache
type=inline
Inside the pushed image itself
Single-stage images you push anyway; saves only final-image layers
type=local
A directory you save with actions/cache
Setups that need the cache as files; more YAML to rotate it
Order the Dockerfile so the lockfile is copied and dependencies installed before the rest of the source, or every code change invalidates the install layer. The full guide, with branch scopes, is Docker layer caching on Sengi; every other cause of a slow build is in slow Docker builds in GitHub Actions.
How much faster is a cached build?
Measured on sengi-standard-4-ubuntu-2404 on September 30, 2026, with the workflow above and a Node.js and TypeScript image: the build step took 68 s cold and 36 s warm after a one-file change, 1.9× faster. The runner adds its own speed on top: a production Docker image built in 7m34s on Sengi against 14m36s on GitHub’s 4 vCPU runner, at $0.045 a build against $0.175. See the runner comparison.
Frequently asked questions
Why is my Docker build not using the cache?
Check four things: the job runs docker/setup-buildx-action (the default docker driver cannot export a cache), the build has both cache-from and cache-to, a multi-stage build uses mode=max, and the Dockerfile copies the full source after installing dependencies rather than before.
How do I check that the Docker cache worked?
Read the build step's log. BuildKit prints importing cache manifest from gha near the start when it finds an earlier cache, and marks each restored layer CACHED. A layer that ran again shows its command output and a duration instead.
Is there a size limit on the Docker layer cache in GitHub Actions?
type=gha stores layers in the GitHub Actions cache, which includes 10 GB per repository. When it fills, the oldest entries are evicted first, so give each image its own scope and avoid caching what you do not reuse.
Does Docker layer caching cost extra on Sengi?
No. On Sengi, type=gha is served from Sengi's own cache and included with every runner, along with actions/cache and the setup actions' caches. The workflow needs no change beyond runs-on.
The fastest hardware for your GitHub Actions.
AMD Ryzen 9 7950X3D desktop CPUs boosting past 5 GHz, on bare metal with local NVMe, a fresh VM for every job, and 2 vCPU jobs ready in 2 seconds. Builds finish up to 1.9× faster than on GitHub’s runners, and at up to half GitHub’s price per minute they cost up to 74% less per build. Change one runs-on line, or give your coding agent one prompt and it opens the pull request for you.
