Reuse Docker build layers across runners
Restore image layers from a persistent cache so new runners can avoid rebuilding unchanged stages.
How companies used this technique
Read what each company changed and follow the original sources.
Restore image layers from the registry cache
Confidence's CI build on pushes to main writes its Docker layer cache to the container registry. The change builds the release deployer image from a target in the shared Dockerfile and adds cache-from for that registry cache, so the release build restores the layers CI already built.
- Use it when
- One workflow builds images with a layer cache, and another builds from the same Dockerfile without one.
- Before applying it
- Release builds read the cache that default-branch CI writes, so keep write access to trusted builds.
Persist Docker build layers across runners
Stripe sync-engine added BuildKit registry caches for its image builds, separated by architecture, so the dependency install layer is reused and only the source copy layer rebuilds.
- Use it when
- Container dependency layers rebuild on every ephemeral runner.
- Before applying it
- Keep registry credentials and cache writes inside the trusted boundary, and verify cold and warm builds produce equivalent images.
Company Playbooks
- Read Anthropic’s playbookRun only affected tests
- Read DoorDash’s playbookRun build and test in parallel, sharded across CI agents
- Read Linear’s playbookBenchmark the same job on faster hardware
- Read Mastra’s playbookStarSling runners for the slowest test workflow
- Read OpenAI’s playbookRank CI fixes by the minutes they save
- Read Ramp’s playbookMove a CPU-bound test suite to a faster CPU
- Read Shopify’s playbookLet an agent iterate against one CI metric
- Read Spotify’s playbookBuild arm64 on native arm64 runners
- Read Stripe’s playbookRun only the tests a change can reach
- Read Uber’s playbookBuild the merge-queue speculations most likely to be needed