Technology leadershipPeople · Systems · Delivery

Notes

DevOps5 min read

Docker finally clicked — works on my machine, everywhere

Docker isn't a lighter VM — it's a build artifact for your entire runtime. The same bytes that pass CI are the bytes that run in production.

My onboarding document for new developers used to be four pages long. Install this PHP version — no, not that one. Enable these extensions. Match this MySQL minor version or the collation will bite you. Copy this config, edit these six lines, and if you're on Windows, God help you. Every new hire lost their first two days to it.

"Works on my machine" was our biggest bug

We had bugs that existed only in production, bugs that existed only on the one designer's laptop, and a staging server that had drifted so far from production it was testing a different application. I'd flirted with Vagrant — better, but a full VM per project made my laptop sound like a jet engine.

The click

Docker clicked for me the day I understood it isn't a lighter VM — it's a build artifact for your entire runtime. The same image that passes CI is the image that runs in production. Not "the same versions, probably." The same bytes.

  • docker-compose replaced the onboarding doc. New developer setup went from two days to: install Docker, run one command, get coffee.
  • The Dockerfile became documentation that can't lie. Every system dependency, declared in one reviewable file — the four-page doc could rot; this can't.
  • Staging drift died, because staging stopped being a server we maintained and became an environment we recreated.
A container is a promise: what you tested is what you shipped.

Honest costs: image sizes surprise you (our first image was 1.4 GB of mostly nothing — learn multi-stage builds early), and file-watching performance on Windows and Mac was painful. But I'll take those trades. We stopped debugging environments and went back to debugging code — which, it turns out, is the job.