"Works on My Machine"

Narrated

You push a new feature. Everything works perfectly in development. You’ve tested it. You’ve clicked every button. It’s solid.

You deploy it. The app crashes.

The error message says something about a missing module. Or the wrong version of Node. Or a system library that exists on your laptop but not on the server. You didn’t change anything about how the app runs. You just added a feature. But the deploy environment is slightly different from your development environment, and that slight difference is enough to bring everything down.

You fix it. You figure out the right version, install the missing thing, redeploy. It works. Two weeks later, the same thing happens with a different dependency. And two weeks after that, a teammate tries to run your project on their computer and gets a completely different set of errors.

This is one of the oldest problems in software. “It works on my machine.” Four words that have caused more frustration than almost anything else in this field. Your machine has Node 20. The server has Node 18. Your machine has an image processing library installed because you used it for a different project. The server doesn’t. Your machine is running macOS. The server is running Linux. Every difference is a potential landmine.

The industry solved this with containers. The idea is deceptively simple: instead of installing your app on a computer and hoping the computer has everything it needs, you package the computer itself. You put your app, its dependencies, its runtime, its configuration — everything — into a single box. That box runs the same on your laptop, on the server, on your teammate’s computer, on any computer in the world.

That box is called a Docker container. And after this lesson, “works on my machine” means it works everywhere.