If Zigbee2MQTT stopped starting after you updated to 2.13.0 and the log points at your Node.js version, here is what happened. The project removed Node.js 20 support in that release because Node 20 reached its own end of life. This is a research-synthesis piece: no bare-metal Node upgrade was performed on a test instance for it. Everything below happens on your own host, with no vendor cloud involved at any point.
What changed in 2.13.0
Zigbee2MQTT 2.13.0 shipped on 2026-08-01. Among the changes, the maintainers removed support for Node.js 20, citing its end-of-life status, and the release notes tell bare-metal users to move to Node.js 24 or 26. This was not a Zigbee2MQTT-specific decision. Node.js 20 exited its own support window in 2026, and the project stopped supporting a runtime that Node.js itself no longer patches.
What that looks like in practice is not a warning you can scroll past. Zigbee2MQTT checks the running Node.js version when it starts and refuses to run on one it does not support, printing the range it accepts alongside the version it found.
Are you affected?
Depends entirely on how you run Zigbee2MQTT.
- Docker or Home Assistant add-on. Not affected by this change. The container image ships its own Node.js runtime, separate from whatever is installed on the host, so the host’s
node -vhas no bearing on it. If this is nudging you toward a container or VM install, our Docker versus VM comparison for a NAS covers what you trade away on the USB side. - Bare-metal or native install (systemd service, manual
npm start, most Proxmox LXC setups). Affected if your host’s Node.js is version 20. This is where the removal bites.
Check your version, then read the error
Run node -v on the host running Zigbee2MQTT. A v20.x.x result is the version 2.13.0 dropped.
The more useful check is the startup error itself, because it names both sides: the range the installed Zigbee2MQTT accepts, and what you are actually running. Historically that range has read like ^18 || ^20 || ^21, and later ^20.15.0 || ^22.2.0 || ^24. It moves with releases, so read it out of your own error rather than assuming.
Two consequences are worth being precise about. First, newer is not automatically safe. Because the supported versions are a list of accepted majors rather than a floor, a version above the list fails the same check as one below it. That is what happened to users who jumped to Node 22 while the list still read ^18 || ^20 || ^21 (GH #22595), and to a user still on Node 16 (GH #20186).
Second, Node 22 is the version this situation is most likely to leave you sitting on, because the official Linux install guide still shows an example verification output in the 20 and 22 range. If node -v reports 22, do not assume you are either fine or broken. Start Zigbee2MQTT and read the range in the error, or check the engines field in the package.json of the version you installed.
The accepted Node majors are an allowlist, not a minimum. v24.x and v26.x are what the 2.13.0 release notes ask for, v20.x is what was removed, and v22.x is the ambiguous case the install doc’s stale example steers people onto. Your startup error is the authority for the build you actually have.
Upgrading Node.js safely
The official install guide walks through installing Node.js via the NodeSource setup script and then installing Zigbee2MQTT’s dependencies. That path is still correct, with one caveat beyond its stale example output. Pin the major rather than relying on a generic LTS alias. NodeSource’s documented pattern is per-major: a setup_24.x script pointing at a node_24.x repository. Node 24 is the current Active LTS line, 24.19.0 as of August 2026, so an LTS alias should land there today. An explicit major is the one you can verify before you run it, and the one that will not move under you at the next LTS rollover.
After installing the new Node.js version, reinstall Zigbee2MQTT’s dependencies (npm ci or npm install in the Zigbee2MQTT directory, following the same steps as the official guide) and restart the service.
If something breaks after upgrading
Two distinct failure modes show up around this release, and it is worth keeping them separate.
Native-module rebuild. When the Node.js major version underneath a project changes, native addons compiled against the old Node ABI throw a NODE_MODULE_VERSION mismatch until they are rebuilt against the new runtime. This is not a Zigbee2MQTT bug. It is standard behaviour for any Node project with native dependencies, and Zigbee2MQTT’s are the serialport bindings that talk to your coordinator, compiled with node-gyp when no prebuilt binary matches your runtime and platform. npm rebuild in the project directory is the standard fix. Your paired-device data is not exposed to any of this, since Zigbee2MQTT keeps it in a plain data file it manages itself rather than in a native database, which is a separate failure mode with its own recovery path.
A separate pnpm version mismatch. An open GitHub discussion tied to the 2.13.0 release (#32717, active as of 2026-08-09) describes a different problem. The project is pinned to pnpm@10.18.3, and users running a newer pnpm major (11.x) hit a failed source build with sh: 1: tsc: not found during the package step. This has nothing to do with the Node.js 20 removal. If your error mentions tsc rather than a Node engine or ABI version, check your pnpm version against what the project expects rather than re-checking your Node.js install.
Proxmox and community-script LXC users
If you installed Zigbee2MQTT via the popular community-scripts.org (formerly tteck) Proxmox LXC script, there is a longer-running, separate problem worth knowing about. An older GitHub discussion thread (opened 2024-09-28, still unanswered as of this writing) documents that installer pinning a stale NodeSource repository URL inside /etc/apt/sources.list.d/nodesource.list. That pin silently blocks apt upgrade from picking up a newer Node.js major until the file is edited by hand. The thread predates the 2.13.0 change by about two years, so it is not direct evidence of today’s issue. But it is the same symptom class, stuck on an old Node major, and it has recurred on that installer before. If apt upgrade is not moving your Node version at all, check that file before assuming the upgrade path itself is broken.
Node 24 or Node 26?
The release notes offer both. The distinction is not that one is LTS and the other never will be, which is the version of this comparison that circulates most.
Node 24 was released in May 2025 as the Current line and entered Active LTS in October 2025, with 24.11.0. Node 26 took over the Current slot in 2026 and is scheduled to enter Active LTS in October 2026, at which point Node 24 moves into maintenance: no new features, but fixes continuing into 2028.
The honest answer therefore depends on when you read this. For an instance running your Zigbee network unattended, Node 24 is the pick right now. It is the line under Active LTS today, and it is what a generic LTS alias installs. If you would rather do this migration once instead of twice, Node 26 is defensible given how close its LTS date is, at the cost of running a Current release until then. What is not a good reason to reach for 26 is getting ahead of a support cliff, because Node 24 does not have one for years yet.
Whichever you pick, schedule it for a window where a few minutes of Zigbee2MQTT downtime is acceptable, because restarting the service to pick up the new runtime is unavoidable. That restart does not touch your pairings, and devices stay joined to the coordinator. If entities come back unavailable in Home Assistant afterwards, that is a bridge availability question rather than a Node one. Our coordinator firmware update guide covers the other upgrade people tend to schedule on this host at the same time, and which carries considerably more risk than this one does.