BuildKit cache

Cold builds rebuild every layer. A warm BuildKit cache keeps the build graph hot per project so incremental builds reuse unchanged layers and only the changed work executes. This is the single biggest lever on build time and cost.

Cache entries are content-addressed — keyed by the actual inputs — and the cache store is isolated per project. One project's cache is never readable by another, and never crosses tenant boundaries. There is no shared global cache that could leak layers between customers.

On an owner-edge runner the cache lives on your machine. On a NOME cloud runner the cache is restored into the ephemeral job from the project-isolated store and persisted back at the end. Either way the cache key is the same content-addressed scheme.

Cache invalidates naturally when inputs change — a changed layer input produces a new content address, so stale layers are simply not hit. You can force a clean build to bypass the cache when you need a from-scratch verification.