The Perils of `:latest`: Why Explicit Docker Image Tags Are Crucial

I learned this lesson the hard way. We were setting up a straightforward internal tool – nothing elaborate, just a Dockerized application deployed with Docker Compose on a test server. It was a proof-of-concept, designed for a quick showcase of functionality. Everything ran perfectly: CI/CD pipelines passed, logs were silent, and we moved on.

Fast forward a few weeks. It’s 4:45 PM, I’m wrapping up for the day, about to head out for dinner. Ping! A Slack notification. Our CI/CD pipeline was failing on deployment.

What had changed? I immediately jumped into Datadog, checked the logs, and found this unwelcome message from PostgreSQL:

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

My face at that moment? Exactly like this: panic, confusion, and instant regret.

Photo by Photoholgic on Unsplash

Wait, what? After some intense 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 completely broke our entire environment.

What Does the latest Tag Really Mean?

The :latest tag doesn't signify “most stable” or “safe to use.” In Docker, latest is simply the default tag assigned when you don't explicitly specify one. If you run:

docker pull node

You are, in fact, running:

docker pull node:latest

And the definition of latest? It's whatever the image maintainer designates it to be at that moment. This could change tomorrow, or it might have changed five minutes ago. So, if you run a container without setting an explicit tag, you're placing your infrastructure at the mercy of someone else’s decisions.

(For best practices, refer to Docker Image Tagging Best Practices (Official Docs))

Why latest Is a Lie (and Dangerous)

Here’s why relying on latest will inevitably cause problems for you:

• It's not predictable. Your builds might pull different versions each time, leading to inconsistent environments.
• No rollback. You can't easily revert to the “previous latest” if something breaks.
• Silent failures. Things might break subtly over time (e.g., collation changes, default configuration tweaks) without immediate warning.
• No audit trail. Good luck tracing which exact image version was running last week when debugging an issue.

This isn't just a Docker-specific problem; it affects Kubernetes, OpenShift, ECS, and even Docker Compose. Any system that fetches images from a registry can fall victim to this trap.

The Day It All Broke: A Real-World Example

Let's revisit my story:

• We had deployed using Docker Compose.
• No explicit image tags were used; just image: postgres (which implicitly means postgres:latest).
• A base image update rolled out a new OS version.
• The collation version changed silently within the updated image.
• Our existing database couldn't start because of the version mismatch.

The result? Our CI/CD pipeline failed, the application went offline, and my dinner plans were canceled. It took hours to trace the issue back to a silent image update.

The fix? We changed our docker-compose.yml from:

image: postgres

To:

image: postgres:15.3-alpine

And it’s been smooth sailing ever since.

3 Reasons You Should Always Set the Tag

Let’s break down why explicit tagging is non-negotiable:

1. Stability: Pinning your Docker images ensures consistent behavior across all environments and over time. Your application runs today exactly as it did yesterday.
2. Debugging and Reproducibility: When an incident occurs, you cannot effectively diagnose or recreate the issue if you don't know the exact image version that was running. Explicit tags like node:18.17.1 make this process straightforward.
3. Controlled Upgrades: You want to upgrade your image on your own terms. Test it thoroughly in staging, and then roll it out deliberately. Don't let an upgrade happen simply because some maintainer decided to update latest.

How to Set Explicit Tags in Docker and Kubernetes

Here's how to ensure you're using explicit tags:

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: Apply semantic versioning to your own images too. Instead of myapp/frontend:latest, use explicit versions like myapp/frontend:1.2.3.

Final Thoughts: Avoid the Trap

If there’s one takeaway from this post, let it be this:

• Never run a container without setting an explicit tag. It's easy to overlook during prototyping or rapid development, 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, and controlled.

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

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