A digest keeps staging and production identical; a tag does not. A tag is a name that a publisher can point at new content. A digest is a SHA-256 hash of the image, so the same digest always means the same bytes. Deploy by digest, and change it deliberately.
What each one is
Docker describes an image digest as a unique cryptographic identifier representing the content of an image. Unlike tags, which can be reused or changed, a digest is immutable and ensures the exact same image is pulled every time. Docker's build guidance says that pinning a base image to a digest means you always use the same version, even if a publisher replaces the tag with a new image.
Kubernetes documentation says the same from the deployment side: an image can be named by tag or by digest, and if you do not specify a tag, it assumes latest. Its docs also advise avoiding the latest tag in production because it is harder to track which version is running and harder to roll back.
Where drift comes from
Suppose staging pulls the image on Tuesday and production pulls it on Thursday, both by tag. If the tag moved in between, they run different content, with different libraries inside. Your scan of staging says nothing about production.
Nodes can add another layer. Depending on the pull policy, a node that already has an image cached may keep using it, while a new node pulls fresh. Two pods of one deployment can then differ.
Trade-offs
| Tag | Digest | |
|---|---|---|
| Readable | Yes | No |
| Same content every time | No | Yes |
| Receives base image fixes automatically | Yes, whether you want it or not | No, you update it yourself |
| Audit trail of what ran | Weak | Strong |
Docker's own guidance names the cost: with a digest pinned, you opt out of automatic security fixes, so you need a process that raises updates. Their suggestion is automated pull requests that bump tags and digests on a schedule, which gives you control plus an audit trail.
A practical pattern
- Build the image once in CI and record its digest.
- Deploy to staging using the digest, not the tag.
- Promote that same digest to production after checks pass.
- Keep a human-readable tag for convenience, but make the deploy manifest reference the digest.
- Schedule base image refreshes as normal pull requests, so staleness is visible and fixed on purpose.
Our post on build once, promote the same artifact goes deeper on step 1 to 3.
Try it yourself
Click through it at your own pace, or open it full screen.
Click through the scan and note that findings attach to a specific image. That is why knowing the exact digest matters.
What Safeguard does here
Safeguard scans container images and monitors them for new advisories, so a finding maps to the exact image you deploy. The free scan is at gold.safeguard.sh/scan.
Quick check
Can I keep both a tag and a digest?
Yes. A reference can include both. The digest decides what is pulled, and the tag is a label for people.
Does pinning a digest make me less secure?
Only if nobody updates it. Pair it with scheduled updates and scans so fixes arrive when you choose.
Sources
Last reviewed: 19 October 2026.
