A junior dev overwriting a production .env file by running `npm install` on the server is a symptom of a broken process, not just a broken command. Here’s how to fix the process, not just the file.

That 3 AM PagerDuty Alert? Your `postinstall` Script Probably Caused It.

I remember it like it was yesterday. 3:17 AM. My phone buzzing on the nightstand with that gut-wrenching PagerDuty alert tone. The one we reserve for “everything is on fire.” The main API for our biggest client was down. Hard down. After a frantic 20 minutes of digging through logs on `prod-api-01`, we found the culprit. The database connection string was gone. Not wrong, just… gone. Replaced with the default `user=root, password=password`. It turned out a well-meaning junior engineer, trying to quickly patch a bug, had SSH’d into the box, pulled the latest from git, and run `npm install` directly on the server. That triggered a helpful little `postinstall` script that dutifully created a fresh, default .env file, wiping out our production credentials.

I wasn’t even mad. I was tired. This is one of those problems that makes you question everything, but it’s not the junior’s fault. It’s a process failure, and one I see all the time. Let’s talk about why it happens and how to make sure it never wakes you up again.

The “Why”: Your Local Setup Script is a Ticking Time Bomb in Production

This whole mess stems from a single, simple misunderstanding of environments. In development, having a script that automatically creates a starter .env file is a fantastic convenience. It helps new developers get up and running in minutes. You run `npm install`, and boom, you have the template you need.

The problem is that this “development helper” script doesn’t know it’s not in Kansas anymore when you run it in production. It executes with the same blind obedience on `prod-db-01` as it does on your MacBook. It sees no .env file (or just overwrites the existing one), and happily creates its default version, effectively nuking your environment-specific secrets. This isn’t a bug in NPM; it’s a flaw in the deployment strategy.

Pro Tip: Your .env files should NEVER be committed to source control. Ever. Add .env* to your .gitignore file immediately. These files contain secrets, and secrets don’t belong in Git history.

The Fixes: From Band-Aids to Bulletproof

There are a few ways to solve this, ranging from a quick fix to a complete process overhaul. Let’s break them down.

1. The Quick Fix: Modify the Script

The fastest way to stop the bleeding is to make the script smarter. You can modify your package.json to prevent the script from running if it detects a production environment. This is a bit of a hack, but it’s effective in an emergency.

You can check for the `NODE_ENV` environment variable, which is a common convention.

In your `package.json`:

"scripts": {
  "postinstall": "if [ \"$NODE_ENV\" != 'production' ]; then node ./scripts/setup-env.js; fi"
}

This tells the package manager: “Only run the `setup-env.js` script if the `NODE_ENV` variable is anything other than ‘production’.” It’s a simple, immediate guardrail.

2. The Permanent Fix: A Real CI/CD Pipeline

Stop building on your servers. I’m going to say it again: stop running package managers in production. Your production environment should be for running code, not building it.

The “right” way to solve this is with a proper CI/CD (Continuous Integration/Continuous Deployment) pipeline using tools like GitLab CI, GitHub Actions, or Jenkins. Here’s the workflow:

• Build Step: The pipeline checks out your code in a clean, isolated container. It runs `npm install` and `npm run build` here. This creates a build “artifact”—a self-contained folder (e.g., a `dist` or `build` directory) with all the necessary `node_modules` and compiled code.
• Secrets Management: Your production secrets (DB passwords, API keys) are stored securely in a dedicated service like AWS Secrets Manager, HashiCorp Vault, or your cloud provider’s parameter store. They are never in a .env file in the repository.
• Deploy Step: The pipeline takes the build artifact and deploys it to your server. It then injects the secrets as actual environment variables during application startup. Your app reads `process.env.DATABASE_URL`, not a file on disk.

This approach decouples your build process from your runtime environment. It’s more secure, more reliable, and completely eliminates the risk of a `postinstall` script causing an outage.

3. The ‘Nuclear’ Option: Use `npm ci` and `–ignore-scripts`

If you absolutely must run a package installation command on a server, you should never use `npm install`. Use `npm ci` instead. It installs dependencies directly from your `package-lock.json` file, which ensures you get the exact same dependency tree that you tested with. It’s faster and safer.

Furthermore, you can explicitly tell NPM not to run any scripts. This is your “break glass in case of fire” command.

npm ci --ignore-scripts

This command does two things:

1. It installs the exact dependencies from your lock file.
2. It completely ignores any `preinstall` or `postinstall` scripts defined in your `package.json` or any of its dependencies. The rogue script will never even get a chance to run.

While this works, it’s still a sign that you’re treating your server like a development machine. It’s a better command, but it doesn’t fix the underlying process flaw.

Choosing Your Path

Here’s a quick breakdown to help you decide.

At the end of the day, these kinds of problems are a rite of passage. They force us to grow and improve our processes. So next time you see something like this, don’t ask “Why are people like this?”. Instead, ask “How can our process be better?”. That’s the first step from being just a developer to being an engineer.

Darian Vance

Lead Cloud Architect & DevOps Strategist

With over 12 years in system architecture and automation, Darian specializes in simplifying complex cloud infrastructures. An advocate for open-source solutions, he founded TechResolve to provide engineers with actionable, battle-tested troubleshooting guides and robust software alternatives.

🤖 Frequently Asked Questions