The Case of the Zombie Code: Why my EC2 refused to update 🕵️‍♂️

Anandh — Thu, 15 Jan 2026 03:07:39 +0000

You know that feeling when you push a brilliant bug fix, the CI/CD pipeline gives you a "thumbs up," and you go to grab a celebratory coffee?

Then you open your app and realize... nothing changed. The code in your browser is the "Zombie version"—the one you thought you killed 10 minutes ago. It’s back from the dead, and it’s haunting your EC2 instance. 🧟‍♂️

The Crime Scene

GitHub Actions: Success.

AWS ECR: The latest image is sitting there with a fresh timestamp.

EC2 Instance: Still running code from last Tuesday.

The Culprit? Docker’s local image cache.

Docker is like that friend who "already has a guy for that." When you tell it to run the latest image, it looks at its own internal shelf first. If it sees an image tagged latest, it says, "I’ve already got it! No need to download anything new." Even if the "new" latest is totally different.

The Investigation: How to Force a "Search and Seizure"
To fix this, we have to perform an "Eviction Notice" on the old image. Here is the play-by-play on how to force your EC2 to stop living in the past.

Step 1: Prove who you are (ECR Login)
You can't take anything from ECR if you don't have the keys.

Bash

aws ecr get-login-password --region YOUR_REGION | docker login --username AWS --password-stdin YOUR_ECR_REGISTRY

Step 2: Stop the "Imposter" Container
We can't update the engine while the car is still driving. Shut it down.

Bash

docker stop backend-app
docker rm backend-app

Step 3: Delete the Evidence (The Cache Buster)
This is the most important step. If you don't delete the local image, Docker will just reuse it. Delete the local copy so Docker is forced to go back to AWS ECR.

Bash

docker rmi YOUR_ECR_REGISTRY/YOUR_REPO:latest

Step 4: The Fresh Start
Now, we bring in the actual "Latest" version from the cloud.

Bash

Pull the actual new image

docker pull YOUR_ECR_REGISTRY/YOUR_REPO:latest

Run the app

docker run -d --name backend-app -p 8081:8081 --restart always YOUR_ECR_REGISTRY/YOUR_REPO:latest

💡 The "Senior Dev" Advice
If you find yourself doing this manual dance every day, it might be time to move away from the :latest tag in your deployment scripts.

The Better Way: Use the Commit SHA as your tag (e.g., my-app:8f2a4b1).

Your GitHub Action builds and tags the image with the SHA.

Your EC2 deployment script asks for that specific SHA.

Docker looks at its cache, sees it doesn't have that specific version, and pulls it automatically. No more zombies.

Closing Thoughts
Docker cache is a double-edged sword. It makes things fast, but it can also make you feel like you're losing your mind. When in doubt: Delete the local image and pull again.

Have you ever spent hours debugging something that turned out to be a cache issue? Share your "war stories" below! 👇

AWS #Docker #DevOps #EC2 #ECR

I got tired of manual DTO mapping, so I built a visual tool for it 🛠️

Anandh — Tue, 13 Jan 2026 12:28:55 +0000

The "Manual Mapping" Nightmare 😱

We've all been there. You’re integrating two services. Service A speaks one version of OpenAPI, Service B speaks another. The fields almost match, but not quite.

What follows is usually an afternoon of:

target.setUserId(source.getUUID());

target.setCreatedAt(source.getTimestamp());

...multiplied by 50 fields.

Before you know it, your service layer is 40% "glue code" and 60% MapStruct configurations that only three people in the company understand.

I decided I'd had enough.

Introducing EasyMap: Visual Mapping for OpenAPI🧩

I'm a senior dev, and I spent way too much time wrestling with these mappers. I wanted a way to see the mapping, not just read it in code.

I built EasyMap to turn that "boilerplate hell" into a visual drag-and-drop experience.

How it works:

Upload your specs: Import your source and target OpenAPI JSON/YAML.
The Visual Canvas: Literally drag a line from the source field to the target field.
Keep it Clean: All that mapping logic stays outside of your business code.

Where it stands today (and where it's going) 🚀

Right now, the tool is a lean MVP focused on Spring Boot integrations. I've been using it to streamline my own workflow, but I'm building it to be framework-agnostic.

On the roadmap:

🐍 Python support (FastAPI/Flask devs, I see you!)

🟦 TypeScript / Node.js support

Advanced transformations (for those "dirty" mappings)

Try it out & Break it! 🧪

It’s in the early stages, and I’m looking for honest peer feedback to see if I’m on the right track.

Live App: https://easymap.valorio.io

Spring Boot Sample: https://github.com/valorio-io/easymap-integration-springboot-sample

I'd love to hear from you:

Is "visual mapping" something you'd actually use, or do you prefer the "safety" of raw code?
What’s the most annoying part of your current integration workflow?
What’s the one feature that would make this a "must-have" for you?

Thanks for reading! Happy coding. ☕

Forem: Anandh

The Case of the Zombie Code: Why my EC2 refused to update 🕵️‍♂️

The Crime Scene

GitHub Actions: Success.

AWS ECR: The latest image is sitting there with a fresh timestamp.

EC2 Instance: Still running code from last Tuesday.

Pull the actual new image

Run the app

AWS #Docker #DevOps #EC2 #ECR

I got tired of manual DTO mapping, so I built a visual tool for it 🛠️