Snapshots you can replay
"Pin this build’s dependencies and rebuild it in two years" is a promise about the future, and a retention window is a rule that quietly revokes it. A snapshot is the answer: a named, frozen set of exactly what was here, protected from collection, and checkable afterwards.
It freezes the set, not the bytes
A snapshot copies nothing. It records which artifacts existed at one instant, with each one’s digest, size, and verification provenance as of then — a snapshot that duplicated a 400 GB mirror would be a backup, and nobody would take one.
The freeze happens inside the database in one statement, so the set cannot change between reading it and writing it. What it protects is real: while a snapshot exists, its members are not offered to garbage collection at any retention window, and that protection is deliberately NOT tied to the pin setting — a pin is a preference about one artifact, a snapshot is a promise about a named set.
Verify gives a three-way answer
Re-hashing every member against the digest it had at freeze time separates three situations that a boolean would collapse: present and identical, present and CHANGED, and gone. The middle one is the reason to do it at all — bytes replaced under a name they no longer match is the incident nothing else in a mirror can see.
Anything that could not be checked is reported as unknown, and unknown is not a pass: a snapshot is intact only when nothing is missing, nothing changed, and nothing was uncheckable.
Immutable by name
A snapshot cannot be re-taken under a name that already exists; that is a refusal, not an overwrite. A build pins itself to the NAME, so a name that can be re-pointed at a different set makes every such pin a lie.
Deleting one removes no bytes. It withdraws the protection, and the ordinary retention rules apply again at the next sweep — which the CLI, the dashboard, and the MCP tool all say out loud, because "delete" in a storage tool reads as "free space".
What it costs
Stated plainly, because a claim with no stated cost is the one nobody re-checks.
A snapshot needs the catalog. With no database configured the mirror still proxies and caches, and this endpoint answers 503 rather than pretending.
It protects members from collection, which means a long-lived snapshot of a large mirror pins that storage indefinitely. That is the trade being made on purpose, and it is why deleting one is cheap.
Verify reads every byte of every member. On a large snapshot it is slow, so it is a command you run rather than something any page does on load.