If every deployment pins its image by digest, what does that guarantee and what does it now cost the team?

## What a pinned reference actually guarantees A reference naming a content digest has exactly one possible outcome per host: it resolves to those bytes, or it does not resolve. There is no third case in which it quietly resolves to something else. That single property buys four things that are otherwise surprisingly hard to get: - **Fleet uniformity.** Every replica runs the same content, including replicas started weeks apart, because the name cannot have come to mean anything different in between. - **Site uniformity.** Two data centres deploying the same reference at different times cannot diverge, which is the entire failure that unpinned references produce. - **Late-joiner uniformity.** A host added during a scale-up resolves the same digest and therefore starts the same bytes as the hosts that were already there. - **An answerable record.** The deployment record is now evidence rather than intent: it names the content, so "what was running" has an answer even after the replicas are gone. Note what it does **not** buy. A digest fixes *which* bytes run. It says nothing about who produced them, whether they were reviewed, or whether they are permitted to start. Those judgments live elsewhere, and a carelessly built image pins just as perfectly as a carefully built one. ## What freezing the reference costs The same immutability that stops drift also stops improvement. A fix — to the application, to a library, to the base the image was built on — produces a **new** image with a **new** digest. Nothing about the pinned deployment changes until somebody edits the reference. That has a specific and predictable consequence: - application changes still flow, because every one of them produces a new reference as part of the change anyway - **base-image and dependency fixes stop flowing**, because an image rebuilt only to absorb a package fix changes nothing anyone is actively working on, so nobody raises the change Months later the fleet is running exactly the content that was reviewed — and exactly as old as the day it was reviewed. This is the characteristic failure of pinning done halfway, and it is why "pin everything" is only half a policy. ## The update path that makes pinning survivable Pinning replaces an implicit update mechanism with an explicit one, so the explicit one has to be built: 1. **Something watches.** An automated component follows the human-facing label the publisher still maintains, and notices when it points at content the fleet is not running. 2. **Something proposes.** It opens a change that swaps the old digest for the new one, carrying the label and the build it corresponds to so a reviewer can see what is being adopted. 3. **Something reviews.** The change goes through the ordinary review, because a digest bump is a code change in every way that matters. 4. **Something rolls it.** It is released like any other change — progressively, with the same checks and the same rollback target, which in this case is the previous digest and is exact. Done this way the fleet gets both properties at once: it is always running content someone explicitly chose, and it is never more than one review cycle behind a published fix. ## Pinned against unpinned | | reference names a moving tag | reference names a content digest | |---|---|---| | what starts on each host | whatever the label meant when that host read it | one exact image, always | | how a fix arrives | by itself, on the next resolution | only when the reference is changed | | what the record proves | which label was in use | which content ran | | what a rollback targets | a label that may itself have moved | an exact previous identity | | characteristic failure | silent divergence between hosts and sites | a fleet that quietly stops absorbing fixes | ## Where pinning is not the right default The trade is worth taking wherever you would have to account for what ran: production, anything under audit, anything where two environments must be comparable. It is worth much less in a short-lived development environment or a scratch cluster, where picking up the newest build automatically is the point and nobody will ever ask what was serving at 03:00. Setting the standard is a matter of deciding which of your environments are in the first category and then funding the update path for them — a policy that mandates pinning without staffing step 2 above produces an old fleet and a bad reputation for a good practice. The last thing worth saying out loud is that tags do not go away. The label remains the human-facing name, the thing the change conversation refers to and the thing the automated watcher follows. What changes is that the label names the *intent* while the digest is what the deployment actually carries, and both are recorded side by side.