Why You Shouldn’t Use :latest Tag

Why You Shouldn’t Use :latest Tag

You’ve likely seen it or even used it ‘image: yourapp:latest’

It’s everywhere. Dockerfiles. Helm charts. Terraform modules. CI/CD pipelines default to it. Kubernetes accepts it without a fuss.

But here’s the catch : latest doesn’t mean newest.

It means whatever image someone last tagged as :latest, which could be something built five minutes ago, five months ago, or by mistake.

Real World Failures Caused by :latest

Let’s talk about what actually breaks when :latest sneaks into your environment:

1. Kubernetes Deployment Drift

Let’s say a team shipped a Helm release with ‘image: backend:latest’

It worked in staging. But in production, a different developer had pushed their own local :latest. Same tag, different code.

Pods pulled the wrong image. The app broke silently.

2. CI/CD Instability

A GitHub Actions pipeline built and pushed :latest.

Another pipeline, triggered hours later, ran integration tests using the same :latest, expecting the original build.

But a new commit had already overwritten it. Tests failed. Everyone thought the code was broken, when in reality, the image had changed mid run.

3. Terraform’s Dirty State

An AWS ECS deployment managed via Terraform had a task definition pointing to :latest.

After a redeploy, ECS fetched a different image from what was previously running, even though no infrastructure change was made. Terraform applied cleanly. The app didn’t. Likewise, I can go on and on and on…

Let’s Look at What’s Really Going On

Here’s how image tagging behaves behind the scenes:

# Build and tag version 0.1

docker build -t techopsapp:0.1 .

# Build again without specifying a tag

docker build -t techopsapp .

(This is tagged as 'techopsapp:latest' by default)

# Build version 0.2

docker build -t techopsapp:0.2 .

(Unless you manually re tag or push 'latest' again, it still points to the earlier build)

The key point: ‘latest’ doesn’t track anything automatically.

Instead, Try this:

1. Use semantic versions or commit SHAs

docker build -t techopsapp:1.3.7 -t techopsapp:commit-b6fa2e1 .

2. Pin digests in deployment manifests

image: techopsapp@sha256:abcdef123...

This guarantees exact image reproducibility across clusters and pipelines.

3. Automate moving tags like :staging, :prod

Only your CI/CD pipeline should assign these. Never push them manually.

4. Enforce policies

Use conftest, kube-linter, or OPA to flag use of :latest

Set CI checks to reject PRs or pushes that reference :latest