Optimizing npm Installs in CI/CD

Running npm ci in your CI/CD pipeline feels like the right move, and it is. It’s fast, deterministic, and consistent. But for most teams, it’s also noisy, redundant, and occasionally wasteful. I used to tack on a handful of flags to make it behave better in CI, and I wrote about that at lowlydba.com/cicd-npm-flags.

Since then, I’ve wrapped those ideas into a GitHub Action called sustainable-npm, which bakes in all the best practices by default. This post revisits those npm flags, explains why they matter, and shows how sustainable-npm makes them automatic.

npm ci does two key things right out of the box:

1. It’s deterministic. It installs exactly what’s in your package-lock.json or npm-shrinkwrap.json.

2. It’s clean. It nukes node_modules before reinstalling to guarantee a fresh environment.

That’s already better than a bare npm install. But CI pipelines have different priorities than local dev: speed, repeatability, and silence namely.

Here’s what most people end up using in CI:

npm ci --no-audit --no-fund --loglevel=error

Skips npm’s built-in vulnerability scan.

Removes the “hey, you could sponsor this package” noise.

Hides everything that isn’t an error.

Together, these flags give you a predictable, quiet, and faster install, exactly what you want in a CI environment.

Instead of manually sprinkling these, and more flags across every workflow, I built a GitHub Action that does this automatically.

sustainable-npm runs npm ci using a curated set of six flags optimized for speed, cleanliness, and consistency. You just drop it in right before your install step, and you’re good to go!

If you’re curious what other settings are also proven to make your installs faster, check out the documentation for more in-depth explanations.

• I was copy-pasting the same npm ci flags everywhere.

• Teams forgot one flag or added conflicting ones.

• CI logs were filled with noisy warnings or redundant audits.

• In aggregate, all these unwanted features led to slower installs, and more expensive hosting costs for my CI.

So I made sustainable-npm to centralize all that. It’s the “set-and-forget” way to get the best of npm ci without the repetitive YAML sprawl.

Here’s how to use it in your workflow:

name: CI
on: [push, pull_request]
jobs:
  build:
    runs-on: ubuntu-latest
    steps:
      - uses: actions/checkout@v4
      - uses: actions/setup-node@v4
      - uses: lowlydba/sustainable-npm@v1
        with:
          audit: false
          fund: false
          loglevel: error
      - name: Install dependencies
        run: npm ci

Above, the action runs something like:

npm ci --no-audit --no-fund --loglevel=error

…but it’s configurable, so you can tweak behavior for different environments (or just use the defaults!)

There’s a literal angle (less CPU time, less wasted compute = less energy use),
and a metaphorical one. Your CI configs become maintainable, consistent, and scalable.

This was the first GitHub Action published to their latest new category, “sustainability”

It’s a small step toward pipelines that are faster and friendlier to the planet.

You don’t need a ton of flags to make npm behave nicely in CI, but you do need discipline and consistency.
sustainable-npm gives you both, and it’s open source, configurable, and boring-reliable 😎

👉 Check it out on the GitHub Action Marketplace for free → lowlydba/sustainable-npm

Share