Node-RED
Browser-based flow editor for wiring devices, APIs and automations together
Node-RED is a Node.js runtime with a browser editor where you drag nodes onto a canvas and wire them into flows that react to MQTT messages, HTTP calls, timers or Home Assistant events. It replaces IFTTT applets, Zapier zaps and the automation tabs of cloud hubs, and it runs the logic on your own box with no per-task quota.
Our verdict on Node-RED#
Node-RED 5.0 landed on 9 June 2026 (5.0.6 in early September) and it raises the floor: Node.js 22.9 or newer, 24 recommended, and the default admin CORS headers are gone. The 4.1.x line is still getting releases, so there is no emergency, but the jump costs you an audit of every contrib node you installed. Understand credentials before you deploy anything. Node-RED encrypts secrets out of flows.json into a separate flows_cred.json with AES-256-CTR, and if you never set credentialSecret in settings.js it generates a key and hides it in .config.runtime.json. Copy just the two flow files to a new machine and every MQTT password, API token and mail login in your flows fails to decrypt, flows stop, and there is no recovery. Set credentialSecret yourself on day one. It is a two-line edit that turns a restore from a rebuild into a file copy.
Who Node-RED is for#
Choose it if
- People whose automations outgrew Home Assistant's YAML but who do not want to write a service
- Anyone gluing MQTT, HTTP APIs, serial devices and a database into one pipeline
- Visual thinkers who debug faster by watching messages move than by reading logs
- Small businesses wiring a label printer, a scanner and a spreadsheet together without paying per task
Look elsewhere if
- Your logic is genuinely complex; a canvas of two hundred nodes is harder to review than fifty lines of Python
- You need multiple people editing safely, because there is one shared editor and one deploy button
- You want strict version control by default; flows.json diffs are readable but not pleasant
What running it actually looks like#
One container, port 1880, and one volume at /data that must be owned by uid 1000 or the container cannot write its own flows. Everything lives in that volume: settings.js, flows, credentials, and the node_modules for palette nodes you install through the editor. That last point catches people who mount nothing and lose every installed node on the next image pull. There is no authentication out of the box, so a fresh instance on a LAN address is an open editor, and a function node executes arbitrary JavaScript as the process user; uncomment adminAuth before it leaves your desk. First run is a blank canvas. Upgrades are a tag bump, but a Node.js major change means palette nodes with native bindings need rebuilding.
Resource profile#
- Memory
- 110 MB idle, around 260 MB in ordinary use. A single Node process. Every palette node you install is loaded into it, so a heavily extended instance drifts upward; a contrib node with a leak is the usual cause of steady growth.
- CPU and acceleration
- Near zero at rest. Function nodes run on the one JavaScript event loop, so a single blocking loop stalls every other flow. The heavy load is in your browser: a canvas with several hundred nodes gets sluggish long before the server does.
- Storage growth
- Small and stable: flows.json, the credentials file, settings.js and node_modules for whatever you install, normally under 500 MB. Nothing grows on its own unless a flow writes files or a debug node logs to disk.
- Operational load
- 2 of 5, Light. One container, config is a directory of JSON, and a restore is a file copy provided you hold the credential secret. The cost is dependency churn: palette nodes lag major Node-RED and Node.js releases, and native modules need rebuilding after a Node major bump.
Figures describe a small single-household install and are the working assumptions behind our stack planner. Your numbers will differ with library size, user count and hardware. See methodology.
Data and backup surface#
Back up the whole /data directory (or ~/.node-red for an npm install): settings.js, flows.json, flows_cred.json, package.json, and the hidden .config.runtime.json and .config.nodes.json. Plain file copies are safe; these are JSON files rewritten on deploy, not a live database. .config.runtime.json is the one people miss, because it carries the auto-generated _credentialSecret that decrypts your credentials file. node_modules is regenerable from package.json with npm install, so exclude it and save yourself a few hundred MB. If you enable projects mode, flows move into a git working tree under /data/projects, and any backup script pointed at the old paths quietly captures nothing.
Derived backup shape
File copy. Copy the config and data directories. Safe while running for anything that writes atomically.
Traps and surprises#
The credential secret that silently breaks a restore
If credentialSecret is unset, Node-RED invents a key and stores it in .config.runtime.json. Restore flows.json and flows_cred.json onto a new host without that file and every credential fails to decrypt; flows stop with a credentials error and the values are gone. Set credentialSecret in settings.js to a string you keep in your password manager, redeploy once to re-encrypt, and restores become a copy. Once set, changing it destroys existing credentials.
No authentication by default
A stock install serves the editor to anyone who can reach port 1880, with no login. That is not just read access to your flows and their configured hosts: a function node runs arbitrary JavaScript in the Node-RED process, and the exec node runs shell commands. Set adminAuth in settings.js with bcrypt hashed users (node-red admin hash-pw), and do not port-forward 1880 on the theory that nobody knows the address.
Palette nodes live in the volume, not the image
Nodes installed from the editor land in /data/node_modules, which is why the volume mount is mandatory rather than convenient. Some nodes (serialport is the classic) compile native bindings against the running Node.js version, so upgrading to 5.0 and its Node 22.9 minimum can leave them failing to load with an ABI error. The fix is npm rebuild inside the data directory, not reinstalling Node-RED.
Full deploy restarts everything, including connections
The deploy button defaults to Full, which stops and restarts every flow: MQTT sessions reconnect, inject timers reset, and anything holding in-flight state loses it. On a busy instance that is a visible outage in the middle of editing one node. Switch the deploy dropdown to Modified Nodes for routine edits and keep Full for structural changes.
Specifications#
- Category
- Home automation
- Licence
- Apache-2.0 (Permissive)
- Written in
- JavaScript / Node.js
- First release
- 2013
- Maturity
- Mature
- Datastore
- JSON files on disk (flows.json and an encrypted credentials file)
- Default ports
1880- Ships as
- docker, npm global install, home assistant app
- arm64 builds
- Yes
- Identity
- OIDC via plugin. `adminAuth` in settings.js accepts local users or any Passport strategy, so OAuth2 and OIDC work through an installed strategy module rather than a built-in provider.
- Replaces
- IFTTT, Zapier, Make, SmartThings automations
- Project site
- nodered.org
- Source
- github.com/node-red/node-red
- Documentation
- nodered.org/docs
Alternatives to Node-RED#
Everything else in home automation, closest in operational weight first.
| Tool | Ops load | Idle RAM | Licence |
|---|---|---|---|
| ESPHome | 2, Light | 150 MB | MIT (Python tooling) and GPL-3.0 (C++ device runtime) |
| Zigbee2MQTT | 2, Light | 90 MB | GPL-3.0 |
| Frigate | 3, Moderate | 700 MB | MIT |
| Home Assistant | 4, Heavy | 600 MB | Apache-2.0 |
Where Node-RED comes up elsewhere#
Head to head
Migration guides
Sources#
Facts on this page were checked against the project's own material. Where a number is our own estimate rather than a published figure, the text says so.
Published . Last reviewed . Found something out of date? Tell us and we will fix it and log the change.