How docker fixes the problem of it works on my machine?

I'm Saroj Bist, a self-taught web developer, learning and building with the MERN stack. I started with front-end tools like ReactJS and Tailwind CSS, and slowly stepped into full-stack development, working on real projects and solving real problems. This blog is where I share what I’m learning — from small bugs to full project insights — in a way that helps both me and anyone on a similar path.
I once built a Spring Boot app that worked perfectly on my laptop.
But when I deployed it to a server, it failed instantly because the server had a different Java version. Before Docker, a typical situation always looked like this:
We build an app on our laptop, and everything works fine.
Then when we deploy or share it, it breaks.
Root causes:
Different OS (Mac vs Linux vs Windows)
Different runtime versions (e.g., it works on Node 18 locally, but production runs Node 20 and suddenly things break)
Missing dependencies
Missing or incorrect environment variables (like DB URLs, API keys)
Different system libraries
How Docker Fixes This (Core Idea)
Docker says:
Docker solves this with a simple idea:
“Don’t just ship your code — ship everything your code needs to run.”
What Actually Happens Under the Hood
1. We define environment in a Dockerfile
Example (Spring Boot mindset)
FROM openjdk:17
WORKDIR /app
COPY target/app.jar app.jar
CMD ["java", "-jar", "app.jar"]
This says:
Use Java 17
Run this JAR
Inside a controlled environment
Each container runs in isolation, meaning it has its own:
File system
Dependencies
Runtime
Because of this, our application does not depend on whatever is installed on the production server.
Instead, it runs using the environment we defined in the Docker image.
As long as Docker is available, the application behaves the same across different machines, whether it's our laptop, a VPS, or production.
2. Docker builds an Image
Think of it like:
A frozen snapshot of my app + environment
3. Everyone runs the same container
Now:
My laptop
My VPS
Production server
All run the exact same image!
Think of a Docker image like a pre-configured box that contains:
Our app
Java runtime
Required libraries
Wherever we run this box, it behaves the same.
As a developer, I often ran into a common problem, different projects needed different environments.
Sometimes I needed one version of Java, sometimes another. Setting them up manually, switching between versions, and managing configurations quickly became messy and time-consuming.
With Docker, this problem simply disappears.
Instead of installing multiple Java versions on my system, I can define exactly what I need inside a container:
FROM openjdk:17
If another project needs a different version, I just change the base image. Each project runs in its own isolated environment, without affecting anything else on my machine.
Trying New Technologies Becomes Effortless
The same applies when experimenting with new tools.
For example, if I want to use Redis, I don’t need to go through the hassle of installing and configuring it locally. I can just pull the official image and run it:
docker run -d -p 6379:6379 redis:7
That’s it! Redis is up and running in seconds.


