Skip to main content

Command Palette

Search for a command to run...

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

Updated
3 min read
How docker fixes the problem of it works on my machine?
S

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.