n8n9 min readPublished August 2026

n8n 3.0 drops npm installs. That is the smaller half of the problem

Moving your instance into Docker is a scheduled evening of work. The same release deletes nodes your existing workflows are built on, and that half cannot be checked after you upgrade - only before.

What is actually being announced

Two sentences from the n8n changelog decide how a lot of self-hosted instances spend their October:

Self-hosted n8n will require a Docker-based deployment. Installations run via npm / npx n8n will no longer be supported.

The installation page says the same thing from the other end:

npm-based installs are deprecated from n8n 3.0.

And the replacement is explicit that this is not a preference:

From v3, n8n is only distributed through Docker.

Read as an infrastructure change, this is a Tuesday. Install Docker, run one command, move the data directory, point the reverse proxy at the container. A competent person does it in an evening, and the rollback is obvious: the old installation is still sitting there until you delete it.

That framing is exactly what makes the release dangerous.

The two changes wearing one label

A version bump that changes how software is installed feels like a change to where the software lives. This one is two independent changes shipped under one version number:

  1. The runtime moves. Your instance runs in a container instead of on the host. Reversible, testable, and boring in the good sense.
  2. Nodes your workflows are built on are deleted. Not deprecated with a warning banner - removed from the product in the same release.

The first is a migration. The second is a rewrite, and it lands on whoever happens to open the editor afterwards.

The rollback for the first change does not help with the second. You can put the old installation back and be running again in minutes - on the old version, with the old nodes, having made no progress on the thing that will still be waiting for you next time.

What is being removed

Three legacy nodes go:

Function node (legacy)

Function Item node (legacy)

Item Lists node (legacy)

The AI side loses more than a node:

Version 1 of the AI Agent node supported several agent type modes, including SQL Agent, Conversational Agent, OpenAI Functions Agent, Plan and Execute Agent, and ReAct Agent. n8n 3.0 removes version 1 of the node, along with these modes.

And one expression helper:

The deprecated $getPairedItem expression helper is being removed.

Two capabilities are retired as well: the Chat hub, and workflow import from URL in the editor. That last one matters to anyone whose runbook says "import this URL to restore the workflow" - the runbook stops working before the workflow does.

Why the node removals are the sharp end

Because of who finds them, and when.

The Docker move is done by whoever administers the box, on a date they chose, with the old install still on disk. The node removals are found by whoever opens a workflow after the upgrade - often not the same person, often not on a date anyone chose, and usually at the moment the workflow was supposed to run. If nobody is watching for that, it becomes the failure mode where silence is the symptom and nothing reports it.

There is a second reason, and it is specific to how these particular nodes get used. Function and Function Item are what people reach for when a workflow needs one small piece of real code - a date reformatted, an ID looked up, a payload reshaped. They are rarely the point of the workflow, so they are rarely in anyone's mental inventory of what the workflow contains. Nobody remembers "the invoice flow depends on a Function node". Everybody remembers "the invoice flow sends invoices".

Item Lists has the same property from the other direction: it is the plumbing between two interesting steps. And $getPairedItem is worse than either, because it is not a node at all - it lives inside an expression, in a field, on some node whose name gives no hint that anything inside it is deprecated.

The parts of a workflow that break in this upgrade are exactly the parts nobody describes when they describe the workflow.

The inventory you can take before October

This is the useful work, and it does not require Docker, a test instance, or any decision about when to upgrade. You are answering one question: which workflows contain something that 3.0 deletes?

Every workflow in n8n is JSON, and every JSON export contains the node types it uses. So the inventory is a search, not an audit. Export your workflows - the whole instance, not a sample - and search the export for the identifiers that matter:

bash
# From a directory of exported workflow JSON files
grep -l '"n8n-nodes-base.function"\|"n8n-nodes-base.functionItem"' *.json
grep -l '"n8n-nodes-base.itemLists"' *.json
grep -l 'getPairedItem' *.json
grep -lE '"agent": *"(sqlAgent|conversationalAgent|openAiFunctionsAgent|planAndExecuteAgent|reActAgent)"' *.json

Those identifiers are the ones the nodes carry in workflow JSON, which is why this works on an export rather than requiring you to open anything. Note what the last pattern leaves out: toolsAgent is the mode that survives, so a workflow matching only that one needs nothing from you.

What comes back is not a list of problems. It is a list of workflows that need a person to look at them, which is a much smaller and much more actionable thing than "audit everything before October".

Do this on every workflow the instance holds, not on the ones you remember. Instances that have run for a couple of years accumulate workflows nobody has opened since they were built - and those are precisely the ones built with the older nodes, because they were built when those nodes were the current way to do it.

The replacements, and the one that is not a replacement

n8n names the swaps, and two of the three are mechanical:

  • Function and Function Item become the Code node. The documentation says so directly: "Replace Function and Function Item nodes with the [Code] node." The code inside usually survives with small changes, because the Code node is the same idea with a different item-handling model.
  • Item Lists splits into purpose-built nodes - Split Out, Aggregate, Sort, Limit, Remove Duplicates, Summarize. More nodes, each doing one thing. This is a redraw of that section of the canvas rather than a find-and-replace.
  • $getPairedItem is replaced by standard item linking. This is the one that is not mechanical, because the helper existed to answer a question - "which input item produced this output item?" - and the standard mechanism answers it in a different shape.

The AI Agent case deserves its own line. If a workflow uses one of the removed agent modes, the fix is not a node swap: those modes encoded different reasoning strategies, and the current node does not offer them as options. That work is a rebuild of the agent's behaviour, with testing, and it is the item on this list most likely to eat a week if it is discovered in October rather than in August.

What the migration itself looks like

For completeness, since it is the part everybody expects to be hard and is not. The one-line setup does the work:

bash
curl -fsSL https://get.n8n.io | sh

The documentation describes what that does: it "Checks that Docker is installed and running, and tells you how to fix it if not. Creates a new folder called n8n in your current directory to hold everything. Writes the configuration files n8n needs to run. Downloads n8n and starts it up." Data ends up in a local ./n8n folder and a Docker volume named n8n-data.

The part that needs care is the existing data. An npm installation keeps its database, credentials and encryption key in its own data directory; a container keeps them in a volume. Moving between them is a file copy, but the encryption key is not optional - credentials restored without the key that encrypted them are unreadable, and n8n cannot recover them for you. Copy the whole directory, not the database file.

Before
  • Upgrade lands in October, nodes are missing, workflows fail one by one
  • The person who finds out is whoever the workflow was supposed to serve
  • Rebuilds happen under time pressure, on the workflows that matter most
After
  • Inventory taken in August: a list of workflows that need attention
  • Rewrites scheduled as normal work, on your calendar
  • The Docker move is what it looks like — an evening, with a rollback

What we would do next

  • Export every workflow and search the export for the removed node types and $getPairedItem
  • Separate the mechanical swaps (Function → Code) from the rebuilds (AI Agent modes, Item Lists chains)
  • Check runbooks and documentation for "import from URL" instructions that stop working
  • Move to Docker on a date you pick, with the old installation kept until the new one has run a full cycle
  • Copy the whole data directory including the encryption key, not just the database

The deadline is October 2026, and the release is scheduled rather than sudden. The instances that will have a bad month are the ones treating this as an infrastructure ticket, because the infrastructure half is the half that goes according to plan.

Sources

  • v3.0 Breaking changes - n8n Docs, read 25 August 2026. The Docker requirement, npm/npx no longer supported, October 2026 timing, the removed legacy nodes, the AI Agent version 1 removal with its agent modes, the $getPairedItem removal, the retired chat hub and workflow import from URL, and the named replacements.
  • Install with npm - n8n Docs, read 25 August 2026. "npm-based installs are deprecated from n8n 3.0", and the supported Node.js range for existing installs.
  • One-line setup - n8n Docs, read 25 August 2026. The install command, what it does step by step, that from v3 n8n is only distributed through Docker, and where data is stored.

Broken workflow? Fix S — $300, 2 business days, fixed price.

Get my quote in 24h

Written by the Fixmation team.