Reuse a snapshot of the build store

Restore the newest store snapshot for the dependency inputs, and save a new one after the component tests.

Prompt

Evaluate and apply this CI technique to my repository: Reuse a snapshot of the build store.

Restore the newest store snapshot for the dependency inputs, and save a new one after the component tests.

Read the technique and its source-backed company examples: https://starsling.dev/ci-playbooks/techniques/cache-nix-store.md

Inspect this repository’s CI workflows, build and test commands, dependencies, and recent run timings. Identify where this technique applies and explain the expected benefit using this repository’s evidence.
Measure a baseline from recent comparable runs: elapsed time, queue time, runner minutes and failures where available. If data is unavailable, say what cannot be measured.
Compare relevant company approaches, checking prerequisites, platform differences and tradeoffs. Rank applicable options by evidence, fit and measurable opportunity; do not present company results as predictions for this repo.
Recommend the smallest safe change, show what checks and fallback paths remain, and ASK ME WHICH CHANGE TO APPROVE BEFORE EDITING ANY FILES.
Only after approval, work on a new feature branch, make one reversible change, and open a reviewable pull request. Never merge or push to a default or protected branch.
Keep required checks, test coverage, deployment and release behavior intact. Validate the change and compare equivalent runs where possible; report limitations and what should be monitored after merge.

View all playbooks

How Shopify used this technique

Read what Shopify changed and follow the original sources.

Reuse a snapshot of the build store

Most of a Tecnix run rebuilt third-party dependencies that change only with flake.lock and packaging/dependencies.nix. Shopify/tecnix#74 caches the Nix store as one snapshot per build variant, keyed by a hash of those files plus the commit, restores the newest snapshot with that prefix, and saves only from this repository's main pushes, pull requests and manually dispatched runs.

Median PR run over 2026-08-10 to 2026-09-29: 61.8 minutes. After the PR, which makes seven changes (among them the cache, pull requests running only the component tests and the cheap flake checks, and separate sanitizer and coverage jobs), with a 20 to 30% hardware spread measured between runs, a later push with a cache hit and no source change ran 4.7 minutes. One sample per row, as the PR reports. Source

Use it when: Fresh runners rebuild the same dependency closure on every run.
Before applying it: The three snapshots used about 4.3 GB of the 10 GB repository cache quota; restore took 0.5 to 2 minutes and save 0.3 to 1.6.

How Shopify used this technique

Reuse a snapshot of the build store

Related techniques

Bake stable dependencies into runner images

Cache package downloads and dependency stores

Cache the directories the build actually uses

Company Playbooks

Related guides

Cache workflow dependencies

Cut repeated test setup

Share setup steps across jobs

Optimize npm installs

Optimize pnpm installs