Skip to main content

Node v3 Base Images

· 2 min read

Overview​

In our last two changelogs, we announced the automatic blocking of script execution in NPM and Yarn, along with our endorsement of pnpm as the safer, long-term solution for Node package management. pnpm stands out for its built-in tooling that lets developers manage an explicit "allowed list" of dependencies permitted to run post-install scripts.

Introducing Our v3 Images​

By default, pnpm respects the ignore-scripts environment variable (NPM_CONFIG_IGNORE_SCRIPTS), which disables all post-install scripts.

This created a conflict:

  • We need to enforce ignore-scripts for NPM and Yarn to maintain security.
  • But we also want pnpm to execute its curated list of safe post-install scripts.

To resolve this, we have released v3 of our Node base images, which make the following changes:

  • Renames npm to npm-unsafe
  • Renames yarn to yarn-unsafe
  • Introduces wrapper scripts for both tools:
    • npm → wraps npm-unsafe and automatically sets NPM_CONFIG_IGNORE_SCRIPTS=true
    • yarn → wraps yarn-unsafe and automatically sets YARN_ENABLE_SCRIPTS=false
  • Removes the ignore-scripts environment variables from the Dockerfile, allowing pnpm to execute its managed, "allowed" list of post-install scripts.

The following disclaimer is automatically added to the top of the output when the npm command is run:

============================================================
⚠️  DISCLAIMER: Package lifecycle scripts are disabled ⚠️
============================================================

Environment variable enforced:
  NPM_CONFIG_IGNORE_SCRIPTS=true

Scripts will NOT run during npm install.

If you need to bypass this restriction (not recommended),
you must explicitly invoke:

  npm-unsafe <command>

⚠️  WARNING: Running with npm-unsafe allows untrusted scripts
    to execute and may compromise your system.

------------------------------------------------------------
From the Skpr Platform Team
============================================================
  • Adopt pnpm for your development projects as the preferred package manager.
  • Upgrade to v3 of the Node base images, which enable pnpm to safely execute its managed list of post-install scripts.

But I Really Want to Use NPM and/or Yarn​

If absolutely necessary (though not recommended), development teams can opt out by explicitly using:

  • npm-unsafe
  • yarn-unsafe

Resources​

New Node Package Manager: pnpm

· 2 min read

Overview​

In light of the recent Shai-Hulud worm attack, we believe it’s important to offer our customers a more secure alternative to the npm package manager.

Why move away from npm?​

By design, npm executes arbitrary scripts across all dependencies—including transitive ones (the dependencies of your dependencies). This creates a risky environment where malicious code can execute unnoticed.

Enter pnpm​

First released in 2016, pnpm has matured into a battle-tested package manager trusted by teams of all sizes. It combines speed, efficiency, and strict dependency management, making it especially well-suited for organizations managing multiple projects and large monorepos.

Key benefits of pnpm include:

  • Fast – Up to 2x faster than other package managers (see benchmark).
  • Efficient – Uses content-addressable storage; all projects share a single source of truth.
  • Strict – Enforces dependency boundaries from package.json.
  • Deterministic – Ensures reproducible installs with pnpm-lock.yaml.
  • Flexible – Doubles as a Node.js version manager via pnpm env use.
  • Cross-platform – Runs seamlessly on Windows, Linux, and macOS.
  • Battle-tested – In production use since 2016.

(Adapted from the official project README.md)

Why this matters now​

For the context of this changelog, the most important feature is script execution control. Unlike npm, pnpm does not automatically run install scripts from dependencies. Instead, it notifies development teams, giving them the choice to explicitly allow or deny execution.

This default safeguard significantly reduces the attack surface for supply-chain exploits like the Shai-Hulud worm.

╭ Warning ─────────────────────────────────────────────────────────────────────╮
│                                                                              │
│   Ignored build scripts: @tailwindcss/oxide, esbuild.                        │
│   Run "pnpm approve-builds" to pick which dependencies should be allowed     │
│   to run scripts.                                                            │
│                                                                              │
╰──────────────────────────────────────────────────────────────────────────────╯

With this in mind, we strongly recommend development teams evaluate pnpm for their development workflows as a replacement for npm.

Available in all base images​

pnpm is avaialble now in all our Node base images.

See here for the full list of images.

NPM Script Execution Disabled

· 2 min read

Overview​

We have disabled NPM scripts in our Skpr container base images as a security measure in response to the Shai-Hulud worm attack.

For more information on the attack see this blog post from Socket.

Changes Applied​

We have added the following environment variables to our Node images.

  • YARN_ENABLE_SCRIPTS=false
  • NPM_CONFIG_IGNORE_SCRIPTS=true

To ensure local development environments are not compromised, we also recommend teams add the following to their .npmrc file:

ignore-scripts=true

Checking Blocked Scripts​

You can identify which scripts are now blocked with:

npm query ":attr(scripts, [postinstall])" | jq 'map(.name)'

Example output:

[
  "esbuild" 👈️ Flagging a dependency that has a postinstall script
]

To see what a blocked script would have executed:

npm view esbuild scripts.postinstall

Example output:

node install.js

You can then manually run the script by pointing to the full path:

node ./node_modules/esbuild/install.js

Include these manual execution steps in your build process where required.

Further Recommendations​

We encourage teams to evaluate alternative Node package managers that have built-in ignore-scripts workflows. For example, pnpm blocks scripts by default and provides a subcommand for approving projects when needed.

Dark mode authentication

· One min read

Overview​

Cluster authentication has improved theming and supports dark mode. Requires 0.34.8 of the cli.

Nginx Static Error Pages

· One min read

Overview​

Provides a mechanism for returning a static page when a non-200 event occurs.

These static pages include:

  • Overview of the error
  • The request ID for tracing
  • Dark mode

These pages are overridable during application packaging and can be customized to align with your sites design.

Pull Request Documentation