“It Works on My Machine” and Other Lies We Tell Ourselves

Every developer has said it. You know you’ve said it. I’ve said it. The code runs perfectly on your machine. Tests pass. The API responds. The database has exactly the right seed data. Life is good.

Then you deploy. And the whole thing collapses like a house of cards in a hurricane.

“It works on my machine” is the most dangerous phrase in software — not because it’s a lie, but because it’s almost always true. Your code does work on your machine. The problem is that your machine is a beautiful, unique snowflake with exactly the right versions of everything, and production is a cold, indifferent server running Ubuntu 20.04 that was last updated in 2022.

The Six Stages of Environment Drift

Stage 1 — Denial: “It must be a caching issue.” Clear the cache. Re-deploy. Still broken. Clear your local cache. It works locally. Something is wrong with the server, obviously.

Stage 2 — Anger: WHO CHANGED THE NODE VERSION? (checks git log — it was you, three weeks ago.)

Stage 3 — Bargaining: “What if I just install this one package globally on the server? It’s fine. It’s just this once.” It is never just this once.

Stage 4 — Depression: You diff every config file between your machine and production. You find 17 differences. You fix all of them. The app still doesn’t work. You stare out the window for 20 minutes.

Stage 5 — Acceptance: You Dockerize the whole thing. The Dockerfile is beautiful. It uses multi-stage builds, non-root users, and the Alpine base image. It runs perfectly in dev. You push it to production.

Stage 6 — Repeat from Stage 1: The production Docker host is running an ancient kernel. Docker doesn’t support it. “It works in my container” becomes the new “it works on my machine.” The cycle continues.

How to Actually Fix It

The real solution isn’t Docker. It’s parity. Your dev environment, CI environment, staging environment, and production environment should be as close to identical as humanly possible. Docker gets you most of the way there. Infrastructure as Code (Terraform, Pulumi) gets you the rest.

But the real, uncomfortable truth is this: “It works on my machine” is a symptom, not the disease. The disease is that you don’t know what’s different between environments. The cure is knowing. Docker, containers, IaC, and CI/CD pipelines don’t magically fix everything — they just make the differences visible. And visible differences can be fixed.

Or you could just add “it works on my machine” to your company’s list of known issues and move on. No judgment here. We’ve all done it.