We’ve all been there. Six hours of coding. Green tests. A clean PR.
You push to production.
Then it happens. A 500 error. CORS nightmare. Missing asset.
You whisper the most dangerous sentence in software: “But... it worked on localhost.”
Welcome to the war.
The 5 Stages of Localhost Grief
Environment Variables
Locally: .env works fine.
Production: One missing API_KEY and your entire app implodes with a vague "Internal Server Error."Case-Sensitive File Systems
Locally: import User from './components/user' works (thanks, macOS).
Production (Linux): Cannot find module. You cry.CORS
Locally: localhost:3000 → localhost:5000? No problem.
Production: https://app.com → https://api.com? Denied. Good luck.The Database Divide
Locally: 12 rows. Queries take 2ms.
Production: 12 million rows. No index. That query now takes 45 seconds."But the build worked locally"
Until the CI runner uses a different Node patch version and your hash changes. Suddenly, the CSS is gone.
The Hard Truth
The gap will never fully close. Cloud changes. Networks lag. Dependencies drift.
But the pain isn't failure—it's engineering.
3 Quick Ways to Suffer Less
Use Docker. Develop in the same Linux container you deploy to.
Kill if (dev) branches. Make local fail as loudly as production.
Test against real dependencies. Hit the actual API. Use the real CDN.
What's your worst "works on my machine" story? Drop it below. Let's trauma-bond. 👇
Top comments (0)