Run a Container Without Setting the Tag? 3 Painful Reasons to Never Use latest

omarfarsaoui

YES, I learned this lesson the hard way.

We were spinning up a simple internal tool nothing fancy. Just a Dockerized app deployed with Docker Compose on a test server. It was a proof-of-concept, something fast to showcase functionality. Everything worked flawlessly. CI/CD ran clean, logs were quiet, and we forgot about it. Fast forward a few weeks. It’s 16:45, I’m shutting down for the day, about to head out for dinner.

Ping!
Slack notification. CI/CD pipeline failing on deployment.
What changed ? I jump into Datadog, check the logs, and spot this lovely gem from PostgreSQL:

The database was created using collation version 2.36, but the operating system provides version 2.41.

My face at this moment, Yes, exactly like this. Panic, confusion, and instant regret.

Photo by Photoholgic on Unsplash

Wait, what? After some digging, it hit me: the container was pulling the :latest tag. The base image had been updated. And just like that, a subtle OS-level difference borked our entire environment.

What Does the latest Tag Really Mean?

The latest tag doesn’t mean “most stable” or “safe to use”.

In Docker, latest is simply the default tag assigned when you don’t specify one. If you run:

docker pull node

You’re really running:

docker pull node:latest

And the definition of latest? It’s whatever the image maintainer says it is at that moment. That might change tomorrow. It might’ve changed five minutes ago. so if you run a container without setting the tag, you’re putting your infrastructure at the mercy of someone else’s decision.

Checkout Docker Image Tagging Best Practices (Official Docs)

Why latest Is a Lie (and Dangerous)

Here’s why relying on latest will hurt you sooner or later:

  • It’s not predictable. Your builds might pull different versions each time.
  • No rollback. You can’t revert to “previous latest” if something breaks.
  • Silent failures. Things might break subtly over time (e.g., collation changes, default config tweaks).
  • No audit trail. Good luck tracing what image version ran last week.

This isn’t just a Docker issue it happens in Kubernetes, OpenShift, ECS, and even with Docker Compose. Anywhere that fetches images from a registry can get bitten.

The Day It All Broke A Real-World Example

Let’s go back to my story.

  • We had deployed with Docker Compose.
  • No explicit image tags. Just postgres (which means postgres:latest).
  • A base image update rolled out a new OS version.
  • Collation version changed silently.
  • Our existing DB couldn’t start.

Result?

  • CI/CD failed.
  • App was offline.
  • Dinner was canceled.

It took hours to trace the issue back to an image change.

The fix? We changed:

image: postgres

To:

image: postgres:15.3-alpine

And it’s been smooth ever since.

3 Reasons You Should Always Set the Tag

Let’s break it down:

1. Stability

Pinning your Docker images ensures consistent behavior across environments and over time. Your app runs today just like it did yesterday.

2. Debugging and Reproducibility

When an incident happens, you can’t diagnose or recreate the issue if you don’t know what exact image was running. Tags like node:18.17.1 make this easy.

3. Controlled Upgrades

Want to upgrade your image? Do it on your terms. Test it in staging. Roll it out deliberately. Not when some maintainer decides to update latest.

How to Set Explicit Tags in Docker and Kubernetes

In Docker Compose:

services:
  db:
    image: postgres:15.3-alpine

In Docker CLI:

docker pull node:18.17.1
docker run node:18.17.1

In Kubernetes (Deployment YAML):

containers:
  - name: app
    image: myapp/frontend:1.2.0

Pro Tip: Use semantic versioning for your own images too.
Not just myapp/frontend:latest, but myapp/frontend:1.2.3.

Final Thoughts Avoid the Trap

If you take one thing from this post, let it be this:

Never run a container without setting the tag.

It’s easy to overlook when you’re prototyping or working fast. But in production or even long-lived test environments it’s a ticking time bomb

  • Never rely on latest.
  • Always pin your images with explicit versions.
  • Treat your image versions like your code versioned, tested, controlled

For more articles on topics check out Let’s Talk About DevOps.

This content is copyrighted. Do not use for AI training or unauthorized scraping.

Related Posts

Leave a Reply