RELEASE FUNDAMENTALS · 4 MIN READ
Tags are labels. Digests identify what you deploy.
Understand container image tags, immutable digests and why artifact identity matters for predictable deployments and rollbacks.
DEPLOYMENT FIELD NOTES
A tag points to an image
A container image reference often ends with a human-readable tag, such as your-app:v1.2 or your-app:latest. Tags make images convenient to select. They are not, by themselves, a guarantee that the selected artifact will remain the same forever.
A registry can associate the same tag with a different image later. If your deployment workflow resolves the tag again, it may get a different artifact even though the reference looks unchanged.
A digest identifies an artifact
An image digest is a content-based identity, commonly shown with a sha256: prefix. A reference by digest identifies specific content, rather than a label that may be reassigned.
registry.example.com/your-app:v1.2IMMUTABLE ARTIFACT REFERENCEregistry.example.com/your-app@sha256:…The digest above is abbreviated. In a deployment record, the full digest is the useful identifier when you need to compare artifacts.
Why this matters when redeploying
Imagine an application is running artifact A. Its image tag is later moved to artifact B. You change an environment variable and want to restart the same application version with that new configuration.
A workflow that simply pulls the tag again could introduce an unintended version change. A workflow that preserves the active artifact can apply the configuration update while keeping A as the selected image.
In iDeployed, Redeploy current version is designed to preserve the active image’s exact artifact. Selecting the saved image is a separate, explicit deployment action.
Keep three pieces of state separate
- Active image: the artifact currently recorded as active for the application.
- Saved image: the configured image to use for an explicit future deployment.
- Latest deployment attempt: the most recent attempt and its outcome.
A failed deployment attempt does not automatically become the active image. A new saved image is not proof that a version change has happened. Keeping these states distinct makes release decisions easier to reason about.
A practical release habit
Before changing an application, check both the human-readable source and its artifact identity. After requesting a deployment, inspect its observed outcome. When selecting a rollback, choose an eligible successful historical artifact and review the current configuration that will accompany it. Tags help you navigate. Digests help you know what you selected.