Container Image Registries & Lifecycle

Container Image Registries and Lifecycle

Every deployment depends on a container image that someone built, pushed, and stored. Over time a registry accumulates thousands of images: release builds, pull-request builds, images with known vulnerabilities, images still running in production, and images nobody has pulled in years. Handled carelessly, this leads to real incidents — a latest tag silently pointing at a different build, a cleanup job deleting the image a production pod needs after a node restart, a Docker Hub rate limit stopping deployments, or a vulnerable base image living on for months.

Managing the image lifecycle means controlling how images are identified, promoted, verified, scanned, cached, and eventually removed.

TL;DR

Tags are movable names; digests (sha256:...) identify exact image content. Deploy by digest or immutable tag.
Enable tag immutability for release repositories so a tag can never point at different content.
Build once, promote by digest between environments instead of rebuilding.
Sign images and attach attestations (SBOM, provenance); verify them at deploy time.
Scan on push and continuously, since new vulnerabilities appear in old images.
Clean up with retention policies, but never delete images still referenced by running or rollback-ready workloads.
Use pull-through caches or mirrors for public images to avoid rate limits and outages.

Quick Example

Build a multi-architecture image, sign it, and promote the exact digest to a production registry:

Deploy by digest so the running image cannot change underneath you:

A retention policy that expires untagged images and old build images while keeping release tags (Amazon ECR):

Core Concepts

Registries and the OCI Model

A registry stores repositories of images following the OCI distribution specification. An image is a manifest referencing configuration and layer blobs by content hash; a multi-architecture image is an index pointing at per-platform manifests. Because layers are content-addressed, images sharing a base image share storage.

Tags Versus Digests

A tag such as 1.8.0 or latest is a pointer that can be moved to new content. A digest is the hash of the manifest and always refers to the same bytes. Deploying a mutable tag means two nodes can run different code after a re-push. Use digests in deployments (GitOps tools and admission policies can resolve and enforce them), and enable tag immutability in release repositories.

Promotion

Building separately for staging and production means production runs bytes that were never tested. Instead, build once, test the image, and copy the same digest to production repositories or retag it — with tools such as crane, skopeo, or registry replication. See CI Pipeline Design and Quality Gates.

Signing and Attestations

Signing with Sigstore's cosign (keyless with CI identities, or with managed keys) proves who built an image. Attestations attach signed metadata: an SBOM listing contents and SLSA provenance describing how and from what source it was built. Admission policies verify signatures and attestations before pods run. See Software Supply Chain Security.

Scanning

Scan images when they are pushed and re-scan stored and running images continuously, because vulnerabilities are disclosed after images are built. Prioritize findings in images that are actually deployed and exploitable, and fix them by rebuilding on updated base images. See Vulnerability Management.

Availability and Access

Pull-through caches proxy Docker Hub and other public registries through your own registry, avoiding rate limits and outages.
Replication copies images to registries in each region where clusters run, reducing latency and cross-region dependencies.
Access control: CI pushes with short-lived credentials; clusters pull with workload or node identities rather than static pull secrets; developers rarely need push access to release repositories.
Image pull policy: with digests, IfNotPresent is safe and avoids unnecessary registry traffic.

Retention and Safe Cleanup

Storage costs and noise grow without cleanup, but deleting the wrong image breaks deployments — often hours later, when a node is replaced and must pull again. Safe cleanup:

Classify repositories: release (keep releases for your support window), build (keep the last N), pull request (expire quickly).
Expire untagged manifests after a grace period.
Before deletion, compare candidates against digests in use — running pods across all clusters, and the previous releases you might roll back to.
Run registry garbage collection where required to reclaim blob storage.

Best Practices

Deploy Digests, Display Tags

Keep human-readable tags for people, and pin digests in manifests that machines apply. Tools can update both automatically.

Rebuild on a Schedule

Rebuild images regularly — not only when code changes — so base image security fixes reach production.

Keep Images Small and Minimal

Smaller images with fewer packages pull faster and have fewer vulnerabilities. See Dockerfile Best Practices and Docker Multi-Stage Builds.

Verify at Admission

Require signed images from approved registries through admission policies, so unverified images cannot run even if someone pushes them.

Common Mistakes

Deploying latest

Cleanup That Breaks Production

Rebuilding for Each Environment

FAQ

What is the difference between an image tag and a digest?

A tag is a human-readable, movable pointer to an image. A digest is a content hash that always identifies the exact same image. Tags can be overwritten; digests cannot.

Should I use the latest tag?

Not for deployments. It changes meaning over time, makes rollbacks unreliable, and hides which version is running. Use explicit version tags and pin digests.

How do I avoid Docker Hub rate limits?

Authenticate pulls, mirror the public images you use into your own registry, or configure a pull-through cache so clusters pull from your registry instead of Docker Hub.

How long should I keep container images?

Keep release images for at least as long as you might need to roll back or reproduce them, often matching your product's support window. Expire pull-request and intermediate build images quickly, and never delete images still in use.

Why scan images that already passed a scan?

New vulnerabilities are disclosed constantly. An image that was clean when built can be vulnerable a month later, so stored and running images need continuous re-scanning.