← All articles

Infrastructure

Docker, explained without the fear

2026-04-25 · 6 min read

Every developer has said it: "but it works on my machine." And it does — because your machine has the right library versions, the right config, the right everything. The server doesn't. Docker exists to end that argument by packing "my machine" up and shipping it along with the code.

What a container actually is

A container is a lightweight package that bundles your application together with everything it needs to run — the right runtime, libraries, and settings — so it behaves the same wherever it lands. Crucially, it's not a full virtual machine. Containers share the host's operating-system kernel instead of each booting their own OS, which makes them small and fast to start. The name is the analogy: like a standardised shipping container, any ship, truck, or crane can handle it without caring what's inside.

Image vs container — the one distinction that trips people up

From Dockerfile to running containers Dockerfile the recipe build Image the blueprint run Container Container Container
A Dockerfile builds an image; an image runs as many identical containers.

Two words that sound the same but aren't:

  • An image is the blueprint — a frozen, ready-to-run snapshot, built from a Dockerfile (a short recipe listing the base system, your code, and how to start it).
  • A container is a running instance of that image. One image can spin up one container or a hundred, and every one of them is identical.
The gist

A Dockerfile builds an image; an image runs as containers. Every container is the same, everywhere — your laptop, a teammate's, production.

Why teams love it

  • Same environment everywhere. Dev, staging, and production run the identical image, so "works on my machine" stops being a defence — and stops being a problem.
  • Easy scaling. Need to handle more load? Run more containers from the same image.
  • Clean isolation. Each container keeps its own dependencies, so two apps needing different versions of the same library can coexist without a fight.

You don't have to love YAML or become a DevOps engineer to benefit. At its heart Docker is just this: describe the environment once, freeze it into an image, and run that exact thing anywhere. The fear was never really about Docker — it was about environments drifting apart. Docker just stops the drift.


DockerContainersDevOps
← Back to the blog