How to Fix 'Works on My Machine' with Docker
For Full-stack developers · Based on Ashok IT Docker & Kubernetes Containerization Method
// TL;DR
Full-stack developers use the Ashok IT Docker method to end 'works on my machine' failures. Instead of blaming code when Dev works but SIT breaks, you recognize the real cause—a dependency version mismatch—and eliminate it by packaging exact versions inside a Docker Image. Write a Docker File for your front end, back end, and database layers, build the image, and push it to a registry. Because the same image runs identically everywhere, environmental issues disappear. And since developers often own the Docker File, learning this is now part of the job.
Why does your code work locally but break in SIT?
Because it's almost never a code bug—it's an environmental issue. When the same code behaves differently between Dev and SIT, the installed software versions differ. Maybe your machine runs Node 18 and the test server runs Node 16, or your local MySQL is 8.5 and staging is 8.0. The Ashok IT Docker & Kubernetes Containerization Method calls this out directly: blaming code when the real issue is a dependency version mismatch wastes hours.
Docker fixes this by standardizing the environment inside the container. You package your code plus exact dependency versions as one unit—the Docker Image—so it runs identically everywhere.
How do you containerize a three-layer app?
Start by confirming your tech stack with exact versions for every layer:
- Front end: e.g., React 18 or Angular 13
- Back end: e.g., Python 3.11 or Java 17
- Database: e.g., PostgreSQL 15 or MySQL 8.5
Do not proceed until every version is confirmed—version conflicts are the primary cause of environmental issues. Then write a Docker File specifying the base OS, each dependency with its exact version, and the location of your code (JAR, WAR, or build output). Build with `docker build -t
The pipeline is always the same: Docker File → Docker Image → Docker Registry → Docker Container. Push to Docker Hub or AWS ECR so your teammates and CI can pull the identical image.
Isn't Docker just a DevOps responsibility?
No—treating Docker as DevOps-only is a listed pitfall. In many projects, developers write the Docker File. That means you should know how to specify dependencies, pin versions, and build images yourself. When you own the Docker File, you own the reproducibility of your app, and you stop shipping bugs that only appear in someone else's environment.
Think in terms of dependencies, not softwares. Angular, Java, Tomcat, and MySQL are dependencies of your application, and Docker manages them so nobody installs them by hand on each machine.
What happens when you need to upgrade a version?
You change only the instruction in the Docker File. Upgrading Angular 13 to Angular 14 or Java 17 to Java 21 is a one-line edit followed by a rebuild and rerun. You never uninstall and reinstall software across environments—that manual churn is the exact 'life without Docker' problem this method eliminates.
Handy commands as you iterate:
- `docker ps` — see running containers
- `docker images` — see available images
- `docker stop
- `docker rmi
Avoid pinning to `latest`—it can resolve to different versions on different builds and quietly reintroduce the conflicts you're trying to kill.
Next step: Write a Docker File for your current project with every dependency version pinned, build the image, run it locally, then push it and have a teammate pull and run it. Confirm identical behavior—that's your proof the 'works on my machine' era is over.
// FREQUENTLY ASKED QUESTIONS
How do I know if a bug is code or environment?
If the same code works in one environment but fails in another, it's almost always an environmental issue—a dependency version mismatch, not a code bug. Docker eliminates this ambiguity by standardizing exact dependency versions inside the container, so identical images always behave the same way.
Should I pin exact versions or use 'latest' in my Docker File?
Always pin exact versions like Java 17 or PostgreSQL 15. Using `latest` is a pitfall because it can resolve to different versions at different build times, reintroducing the exact version conflicts Docker is meant to eliminate. Exact versions keep every environment identical.
Do I need to install my app's dependencies before running the container?
No—your dependencies are baked into the Docker Image. The only software any machine needs is Docker Engine. Installing Angular, Java, or MySQL manually alongside Docker defeats containerization entirely and reintroduces version drift.
Can I use Docker for local development, not just deployment?
Yes. Running your app in a container locally guarantees your dev environment matches SIT, UAT, and Prod because they all use the same image. This is the most reliable way to catch environmental issues before they reach testers or clients.