npm packages in n8n after Pipedream

npm packages are the biggest practical difference between Pipedream and n8n. In Pipedream you wrote import _ from "lodash" and the package was installed for you, with no package.json (Pipedream docs). In n8n, external modules in the Code node are off by default, impossible on n8n Cloud, and a deliberate setup step on self-hosted instances. Check your npm list before you pick n8n Cloud or self-hosted.

What n8n allows

Setup	Built-in Node modules (fs, path…)	npm packages
n8n Cloud	crypto only	moment only
Self-hosted, external task runners, default config	crypto	moment
Self-hosted, internal mode, nothing set	Blocked	Blocked
Self-hosted, allow-listed	Those you list	Those you install and list

Sources: n8n Code node docs ("If you use n8n Cloud, you can't import external npm modules") enable modules, and the default n8n-task-runners.json in the runners image.

Self-hosted n8n 2.x: install and allow-list

In n8n 2.x every Code node runs in a task runner. n8n recommends external mode: a sidecar container from the n8nio/runners image next to n8nio/n8n, with matching versions (task runner docs). Packages are installed and allow-listed on the runner, not on the main n8n container.

1. Extend the runners image (version 1.121.0 or later):

FROM n8nio/runners:<same version as your n8nio/n8n>
USER root
RUN cd /opt/runners/task-runner-javascript && pnpm add lodash date-fns
COPY n8n-task-runners.json /etc/n8n-task-runners.json
USER runner

2. Allow-list the packages in the launcher config n8n-task-runners.json. The default file is locked down and its env-overrides decide what the runner sees, so a plain environment variable on the container is not enough:

{
  "task-runners": [
    {
      "runner-type": "javascript",
      "env-overrides": {
        "NODE_FUNCTION_ALLOW_BUILTIN": "crypto",
        "NODE_FUNCTION_ALLOW_EXTERNAL": "moment,lodash,date-fns"
      }
    }
  ]
}

Start from the default file shipped in the image and edit only these keys; the example above is shortened.

3. Restart both containers and test a Code node with const _ = require('lodash');.

If you run task runners in internal mode instead (n8n calls it "insecure by design" and plans to deprecate it in n8n 3.0), the runner is a child process of the main container, and the environment variables go there.

Pipedream habits that don't carry over

• Version pins in the import. Pipedream accepted import axios from "axios@0.19.2". In n8n you pin the version when you pnpm add in the image, and the code imports by plain name.
• ES import syntax. Pipedream steps use import. The n8n Code node accepts only require(); an import statement fails with a syntax error, so every import line is rewritten.
• One version per instance. In n8n, packages are installed once in the runner image, so all workflows share one version of each package.

Alternatives to npm

Often the package isn't needed at all:

Package used in Pipedream	n8n replacement
axios, got, node-fetch, @pipedream/platform	HTTP Request node
lodash (simple helpers)	Plain JavaScript
moment	Allowed on Cloud too; or Luxon expressions ($now, DateTime)
@slack/web-api, googleapis, stripe	The n8n app node or HTTP Request with a credential
crypto	Allowed on n8n Cloud and in the default external runner config
uuid	require('crypto').randomUUID()

Swapping SDK calls for n8n nodes has a side benefit: credentials live in n8n's encrypted store instead of in code.

How many of your steps are affected?

Our free report lists every npm package per workflow and per step, from your export, in your browser. To test a single step, paste it into the code step checker; it shows what works on n8n Cloud and what needs self-hosted n8n. Hosting trade-offs: n8n Cloud vs self-hosted. Code mapping: Pipedream code steps to the n8n Code node.

Not affiliated with Pipedream or n8n.