Struggling to pull an older or overwritten Docker image tag? Learn why Docker’s local cache causes this and explore three solutions, from the quick digest pull to the permanent fix of immutable tagging.

“But I Pushed It!” – How to Actually Pull an Outdated Docker Image

I remember one frantic Tuesday night, around 2 AM. A hotfix we deployed had a subtle bug, and the call was made: “Roll it back. Now.” Simple, right? Just re-deploy the previous Docker tag. Except, it didn’t work. The deployment system kept pulling the old, locally cached version of the image, completely ignoring the *actual* previous version we’d just re-tagged in the registry. We were stuck, staring at a production server (`prod-api-03`, I’ll never forget it) that refused to pull the code we knew was there. It’s a maddening, hair-pulling scenario that every engineer hits eventually, and it stems from a fundamental misunderstanding of how Docker thinks about tags.

The “Why”: Docker’s Trust Issues with Tags

Here’s the deal. When you run docker pull myapp:1.2.0, Docker first checks if you already have an image named myapp with the tag 1.2.0 locally. If you do, it just shrugs and says, “Got it already, boss,” and doesn’t even bother checking the remote registry. It trusts that your local tag is the source of truth.

The problem arises when a tag is mutable. If someone pushes a new image with the *exact same tag* (a common but terrible practice with tags like :latest or even version tags during development), your local Docker daemon has no idea. The remote registry has changed, but your local machine is blissfully unaware. The tag myapp:1.2.0 on your machine points to an old image digest (e.g., sha256:abc...), while the registry now points that same tag to a new digest (sha256:xyz...).

So, how do we force Docker to look again?

The Fixes: From a Quick Nudge to a New Philosophy

I’ve seen this problem solved a few ways in the trenches. Here are my go-to methods, ranging from “I need this working 5 minutes ago” to “Let’s never have this problem again.”

Method 1: The Quick Fix – Pull by Digest

This is the most direct and surgical way to get the exact image you want, bypassing the tag ambiguity entirely. Every Docker image has a unique, immutable content-addressable identifier called a digest (that long sha256:... thing). You can tell Docker to pull that specific digest.

First, you need to find the digest of the image you actually want. You can usually find this in your container registry’s UI (ECR, Docker Hub, GCR, etc.). Look at the image tag’s details, and you’ll find the digest.

Then, you pull it directly:

docker pull my-awesome-app@sha256:f6f3973633835c66130283c7438f45a2003c2a9c3b802613b306b2f694e92761

This command tells Docker, “I don’t care about tags. Go find the image with this exact unique ID and pull it down.” It’s guaranteed to get you the version you’re looking for.

Pro Tip: This is my preferred method for emergency rollbacks. It’s explicit, unambiguous, and leaves no room for error. Your deployment scripts should ideally use digests, not tags, for production deploys.

Method 2: The ‘Right’ Way – Use Immutable Tags

The real, long-term solution is to fix the process that got you into this mess. Stop reusing tags. Tags should be immutable—once a tag is pushed, it should never be overwritten.

How do you do that? Simple: make your tags unique. A common and highly effective strategy is to use the Git commit hash as the image tag.

# In your CI/CD pipeline
GIT_HASH=$(git rev-parse --short HEAD)
docker build -t my-company/my-app:$GIT_HASH .
docker push my-company/my-app:$GIT_HASH

Now, your image tags look like my-company/my-app:a1b2c3d. Since a commit hash is unique, you are guaranteed to never have a tag collision again. This completely sidesteps the local caching problem because every new build results in a new, unique tag.

A Stern Warning: If you are using :latest in production, please, for the love of all that is stable, stop. The :latest tag is a loaded footgun. It’s a mutable tag that causes confusion and makes rollbacks a nightmare. Ban it from your production deployment configurations.

Method 3: The ‘Nuclear’ Option – Nuke the Local Copy

Okay, sometimes you’re in a hurry. You don’t have time to find the digest, and you just want the machine to grab the newest version of a tag. This is the “brute force” method. You simply delete the local image, forcing Docker to go fetch it from the remote registry on the next pull.

First, remove the local image:

docker rmi my-app:1.2.0

Now that it’s gone locally, the next pull has no choice but to go to the remote registry:

docker pull my-app:1.2.0

This works, but I call it the ‘nuclear’ option because it’s not very elegant. It’s a manual process, and it can have side effects if other containers on that machine depend on that specific (and now deleted) local image tag. It’s a quick and dirty fix, not a strategy.

Choosing Your Battle Plan

To wrap it up, here’s a quick breakdown of when to use each method.

At the end of the day, that 2 AM incident taught us a valuable lesson: be explicit with your infrastructure. Don’t rely on mutable tags and the hope that your local cache matches reality. Implement immutable tagging in your CI/CD pipeline—it’ll save you from a world of late-night pain. Trust me.

Darian Vance

Lead Cloud Architect & DevOps Strategist

With over 12 years in system architecture and automation, Darian specializes in simplifying complex cloud infrastructures. An advocate for open-source solutions, he founded TechResolve to provide engineers with actionable, battle-tested troubleshooting guides and robust software alternatives.

🤖 Frequently Asked Questions