DEV Community

Cover image for Why ‘Works on My Machine’ Is Still a Thing in Modern Web Apps
Mridu Dixit
Mridu Dixit

Posted on

Why ‘Works on My Machine’ Is Still a Thing in Modern Web Apps

We have:

  • Docker
  • Cloud environments
  • CI/CD pipelines
  • Package managers

And yet…

“It works on my machine” still shows up in 2026.

Why?

Because the problem was never just tooling.
It’s environment consistency, assumptions, and hidden dependencies.

Let’s break it down.

🤔 The Illusion of Consistency

Modern tools give us confidence:

  • Same codebase
  • Same repo
  • Same dependencies

So things should work everywhere… right?

Not exactly.

Small differences create big inconsistencies.

**⚠️ Common Reasons It Still Happens
**1️⃣ Environment Variables Drift

API_URL=http://localhost:3000
Enter fullscreen mode Exit fullscreen mode

Locally:

  • everything works

Production:

  • wrong endpoint
  • missing keys
  • silent failures 👉 Env misconfig is still the #1 culprit.

2️⃣ “It’s Installed on My System”

Some dependencies aren’t in your project.

Examples:

  • global CLI tools
  • system-level binaries
  • hidden PATH dependencies

Works locally ❌
Fails on CI/other machines ❌

3️⃣ Different Node / Runtime Versions

node v18 vs node v20
Enter fullscreen mode Exit fullscreen mode

Subtle differences:

  • package behavior
  • build issues
  • runtime bugs

👉 Version mismatch = unpredictable results

4️⃣ Cache Is Lying to You

Things that “work” locally because of:

  • node_modules cache
  • browser cache
  • build artifacts Fresh environment = broken app

5️⃣ OS Differences

Mac vs Windows vs Linux:

  • file paths
  • case sensitivity
  • permissions

Example:

import User from './user'; // works on Mac
Enter fullscreen mode Exit fullscreen mode

Breaks on Linux (case-sensitive).

6️⃣ Hidden Backend Assumptions

Frontend expects:

  • certain API shape
  • specific data
  • seeded database

But:

  • staging DB ≠ local DB
  • API version mismatch

7️⃣ Untracked Local Changes

Local hacks:

  • temporary fixes
  • debug configs
  • ignored files

Not committed → not reproducible

🧠 The Real Problem

“Works on my machine” happens when:

Your app depends on things that are not explicitly defined.

Anything not in:

  • code
  • config
  • environment setup

…is a hidden risk.

✅ How to Actually Fix It

✔ Make Environments Reproducible

Use:

  • Docker
  • Dev Containers
  • consistent setup scripts

✔ Lock Versions

node version
package versions
Enter fullscreen mode Exit fullscreen mode

Use:

  • .nvmrc
  • package-lock.json

✔ Validate Environment Early

Fail fast:

if (!process.env.API_URL) {
  throw new Error('Missing API_URL');
}
Enter fullscreen mode Exit fullscreen mode

✔ Avoid Global Dependencies

Everything should be:

  • project-local
  • version-controlled

✔ Use CI as Source of Truth

  • If it doesn’t pass CI:
  • It doesn’t work.

✔ Seed and Sync Data

  • consistent test data
  • predictable backend state

⚡ Modern Tools Help — But Don’t Solve It

Docker, cloud, and CI reduce the problem.

They don’t eliminate:

  • bad assumptions
  • missing configs
  • inconsistent workflows

🔥 Final Thought

“Works on my machine” isn’t a joke.

It’s a signal.

A signal that your system:

  • isn’t reproducible
  • isn’t predictable
  • isn’t fully defined

Fix that — and the phrase disappears.

Top comments (0)