Snapshot tags on Docker Hub (e.g., `4-snapshot`) are not static — they get overwritten with every new upstream build, sometimes daily. Pinning a compose file to a snapshot tag gives a false sense of stability: a `docker compose pull` or a fresh node pull can silently swap in a newer image with different behavior. The fix is either to pin to a real release tag (e.g., `4.14.3`) which Docker Hub does not overwrite, or to pin by digest (`image@sha256:...`) if a specific snapshot build is needed. The lesson comes from a debugging session with OWASP Dependency-Track containers.
Questions this post answers
Are Docker snapshot tags like `4-snapshot` on Docker Hub static or do they change?
Docker snapshot tags are not static — they are overwritten every time a new build is pushed upstream, sometimes daily. A tag like `dependencytrack/apiserver:4-snapshot` in a compose file will silently pull a different image on the next `docker compose pull` or on any node that hasn't cached it yet, even though the tag string in your config never changed. Teams managing container deployments track image pinning practices and Docker Hub behavior on daily.dev.
How do I pin a Docker snapshot image to a specific build so it doesn't change?
Reference the image by its digest instead of its tag: `dependencytrack/apiserver@sha256:<digest>`. This freezes the exact image layer regardless of whether the tag is later overwritten. Pull the snapshot once, inspect or copy its digest, then substitute it in your `docker-compose.yml` under the `image:` key. Developers locking down container environments for reproducible builds share digest-pinning patterns on daily.dev.
11K Impressions2 Comments