It's a day I want to throw my laptop
The code I deployed blew up in production, so I had to come in on the weekend and I'm fixing it. It worked fine locally, so why the hell won't it work on the server? I don't know if it's an environment variable issue or legacy code, but even after ten years as a developer, this kind of thing is always new. Fuck.
9 answers
Agreed. It's exciting when it works locally, but then why does it blow up when you deploy to the server? lol
It's 99% environment variables.
I had the exact same experience yesterday. Wasted 3 hours because the env didn't get set properly in the Docker image. By any chance, are there any timezone or encoding-related errors in the server logs?
After ten years, that's to be expected, lol. When something like this happens, I first look at the differences between the local and server environments. Check the Node version and package versions, and see if any secrets are missing from the environment variables. Also, just in case, writing logs to files and tracking them is better for your sanity. If you rush to fix it on the weekend, you'll see even less, so take it slow and go step by step.
Got a source? No, I just agree.
Well, that's a bit... It's normal for it to work locally; the server is the one that's weird. But if you've been at it for ten years, you should have expected environment differences by now. Stop blaming only the legacy system.
Legacy code is really something lol. It's not even code I wrote—just fixing someone else's—and it's amazing it works. Keep it up!
It's always a painful reminder that production isn't local.
Honestly, I think it's only natural that things don't run well locally. Servers usually run Linux, while local machines are Mac or Windows. File path issues, case sensitivity, and permission problems are all common. If you just chalk it up to "environment variables," you might miss the real cause. It's a good habit to spin up a Docker container locally and try to reproduce the same environment.