Spack build cache: enable push/pull for faster, reproducible installs

The decision

Should you enable Spack's build cache for your team or CI? The practical question is whether you want to trade disk and network storage for faster installs and less CPU, while keeping reproducibility intact.

Constraints that drive the choice

• Reproducibility surface. A cached binary is only valid for the exact compiler, flags, dependencies and Spack version used to create it. ABI changes, system libraries or Spack upgrades invalidate entries.
• Storage and network. Cache entries are large. Local caches consume disk. Remote caches add network latency and require credentials and access control.
• Trust. Unsigned caches can be tampered with. Signed caches require key distribution.

Supported options compared

Trade-offs to weigh

Speed vs freshness. Pulling a cached binary skips configure, compile and test. That saves CPU minutes in CI. The cost is the risk of serving a binary built against a different toolchain or system library. Spack encodes the hash of the spec, compiler and dependencies into the cache filename, so mismatches generally fail the pull and fall back to source. The fallback is automatic, but a misconfigured remote cache can still block installs if authentication fails.

Storage vs reuse. A remote cache amortizes build cost across teams. A local cache is simpler and avoids network. For ephemeral CI runners, remote pull-only is common. For developer workstations, local push+pull reduces rebuilds after small changes.

Trust. In multi-user environments, enable signing. Spack can sign tarballs with a private key and verify with a public key on consumers. Unsigned caches are acceptable on a single-user workstation but not for shared production artifacts.

Concrete configuration

Run commands as a user with write access to the cache path and, for remote stores, credentials available to the Spack process.

# System-wide or user config, choose one scope
spack config add config:build_cache True
spack config add config:build_cache_push True
spack config add config:build_cache_path /srv/spack/cache

For a remote store, point the path to an accessible URL and set credentials via environment variables or Spack config. Example placeholder for S3:

spack config add config:build_cache_path s3://my-bucket/spack-build-cache

Optional signing. Generate a key pair once, then reference the private key for producers and distribute the public key to consumers via config:build_cache_signing_keys.

spack config add config:build_cache_signing_key ~/.spack/keys/cache.key

Environment-specific control is also possible in spack.yaml under spack: or via spack env config. This keeps cache policy scoped to a project.

Validation workflow without claiming a test run

Enable and create an entry

Create a temporary environment to avoid polluting your main stack.

spack env create cache-test
spack env activate cache-test
spack config add config:build_cache True
spack config add config:build_cache_push True
spack config add config:build_cache_path <local-cache-dir>
spack install hdf5@1.14.0%gcc@13

After a successful install, inspect the cache.

spack buildcache list <local-cache-dir>

Expect to see an entry for hdf5 with a hash derived from the spec. The hash is the practical check that the artifact matches the spec.

Observe a pull hit

Remove the installed package and reinstall within the same environment.

spack uninstall hdf5
spack install hdf5@1.14.0%gcc@13

A pull hit is indicated in Spack's install output by messages about fetching from the build cache rather than running configure and build steps. The install should complete faster than the initial build.

Confirm fallback

Disable the cache temporarily and reinstall.

spack config add config:build_cache False
spack install hdf5@1.14.0%gcc@13

With the cache disabled, Spack should build from source. This demonstrates the fallback path.

Limitations and practical checks

• Cache invalidation. Changing compiler version, compiler flags, or a dependency version changes the spec hash. Old entries remain but will not be used. Bump build_cache_version in config to force a clean slate when you know the ABI changed.
• System libraries. Binaries linked against host libraries are not portable across OS versions or distributions. Keep the remote cache per platform.
• Network and auth. Transient failures fall back to source builds. Authentication misconfiguration can block pulls entirely. Check access by listing the remote path with the same credentials Spack uses.
• Disk growth. Prune old entries periodically. spack buildcache clean can remove unreferenced files.

A practical health check is to compare the spec hash in spack spec -I hdf5 with the filename shown by spack buildcache list. If they match and the install reports a cache fetch, the cache is working as intended.