Docker and Compose
Why latest is a risky Docker image tag
Deploy traceable Docker images with fixed content identifiers or versioned tags and keep rollback evidence.
By AppLaunch Editorial · Reviewed 2026-08-25
Direct answer
A changeable tag such as latest can point to different content over time, so the same Compose file may deploy a different build tomorrow. Use a version or source-code revision tag and ideally record the exact image content identifier that actually ran.
What this means in plain English
A Docker tag is a label attached to an image. The label latest can be moved to different image contents, so the same Compose file may run one build today and another build tomorrow. That makes failures and rollback difficult to explain.
Use a release number or source commit tag and record the image digest, which identifies the exact content. Keep the previous known-good image available. Production should not need to rebuild old code during an emergency just to return to it.
Can you reproduce the running release?
| Traceability | Release maps to a source-code revision and exact image |
|---|---|
| Repeatability | Pulling the reference retrieves the intended content |
| Rollback | Previous known-good reference remains available |
A simple example
Version 2.4.1 is deployed with its recorded digest. Version 2.4.2 later fails its health check. The operator changes the deployment back to the saved 2.4.1 reference and knows it is the same image that worked before—not a newly moved latest tag.
What to do, step by step
1. Tag images with a release or source-code revision.
Start here before buying anything or changing several settings at once. It gives you a clear starting point based on traceability: release maps to a source-code revision and exact image. Write the result down so you can compare it later.
2. Record the exact image identifier in deployment evidence.
Use the same files, versions and settings that the real project will use. A quick test with an empty or different setup can look successful while completely missing the problem you are trying to solve.
3. Retain previous images according to the rollback policy.
Try the busiest realistic situation, not the easiest one. Include the people, data, traffic or background work you genuinely expect, then watch for slowdowns and errors rather than relying on a single headline number.
4. Test rollback without rebuilding.
Finish by checking the result against rollback: previous known-good reference remains available. Keep the old setting or release available until you know the change works and can be reversed safely.
One more useful tip
Do not reuse an old version tag for a rebuilt image. If the content changes, give it a new traceable identity even when the application version looks similar.
Common mistakes and how to avoid them
Reusing version tags.
This gives a misleading or unsafe result because it leaves out traceability. A better approach is to tag images with a release or source-code revision, then check the result before making the change permanent.
Deleting the only rollback image.
This gives a misleading or unsafe result because it leaves out repeatability. A better approach is to record the exact image identifier in deployment evidence, then check the result before making the change permanent.
Building directly on the live host without recording where the code came from.
This gives a misleading or unsafe result because it leaves out rollback. A better approach is to retain previous images according to the rollback policy, then check the result before making the change permanent.
Words explained
- image
- The read-only package used to create a container. A good production image can be rebuilt and traced back to a specific release.
- Compose
- Docker Compose is a file-based way to describe several containers, their settings, storage and networks as one application.
Quick checklist
- Tag images with a release or source-code revision.
- Record the exact image identifier in deployment evidence.
- Retain previous images according to the rollback policy.
- Test rollback without rebuilding.
Common questions
What is the simple answer?
A changeable tag such as latest can point to different content over time, so the same Compose file may deploy a different build tomorrow. Use a version or source-code revision tag and ideally record the exact image content identifier that actually ran.
What should I check first?
Start with traceability: release maps to a source-code revision and exact image. That is usually more useful than choosing from a marketing label or copying somebody else’s setting.
How can I make the change safely?
Tag images with a release or source-code revision. Then change one thing at a time, keep a backup or old version, and use the same real-world test after each change.
What is the easiest mistake to avoid?
Reusing version tags. Avoiding that one mistake makes the rest of the comparison much more trustworthy.