n8n vs Node-RED

Last reviewed Aug 25, 2026 · 642 words

Both put a flow editor in your browser and let you wire boxes together, which is why every automation thread asks this question — and the answer is that they're siblings by interface only. n8n descends from Zapier's lineage: hundreds of pre-built integrations for SaaS APIs, credential management, scheduled and webhook-triggered workflows that run to completion. Node-RED descends from IBM's IoT lab: a runtime for continuous event streams, where MQTT messages, sensor readings, and hardware signals flow through always-live graphs. Pick by problem, not by canvas.

What each is actually for

Give n8n a job like "when a Stripe payment lands, add the customer to the spreadsheet, generate an invoice, notify Slack" and its value is obvious: nodes for each service exist, OAuth credentials are managed centrally and encrypted, runs are logged with per-node inspection for debugging, and error workflows catch failures. Execution is discrete — trigger, run, finish, log — which is the right shape for business processes.

Node-RED's shape is continuous: flows deploy and stay live, processing every message as it arrives. Its gravitational centre is IoT — MQTT in and out as a first-class citizen, serial and GPIO nodes for actual hardware, dashboards for sensor data — and its single biggest constituency is Home Assistant users who outgrow the built-in automation editor: the node-red-contrib-home-assistant-websocket palette makes complex automations (motion-with-conditions-and-timers logic that YAML renders unreadable) into legible visual graphs. At 256 MB and happy on a Pi, it's also the lighter runtime, though neither is heavy.

Licensing and ecosystem, briefly

Node-RED is Apache-2.0, OpenJS Foundation-governed — open source with no asterisks. n8n's Sustainable Use License is fair-code: free for self-hosted internal use (any homelab or business automating its own work), restricted from reselling n8n as a service. For the typical self-hoster this changes nothing practical, but it's a real philosophical line, covered in who pays for open source. Ecosystem shapes mirror the products: n8n ships curated integrations maintained centrally (they mostly just work), Node-RED has thousands of community npm palettes of gloriously variable quality — freedom and jank in the usual proportions.

The overlap zone, adjudicated

Yes, Node-RED can call REST APIs, and yes, n8n can subscribe to MQTT — the overlap tempts people to standardise on one. Two rules of thumb from living with both. If the flow's purpose is moving data between named services on the internet, n8n's pre-built nodes and credential handling will save you writing the HTTP requests Node-RED would make you assemble by hand. If the flow's purpose is reacting to events inside your house — and especially if latency matters, as it does for lights — keep it in Node-RED next to Home Assistant, where a webhook round-trip through n8n would be an architectural detour. Function nodes (JavaScript in both) cover each one's gaps identically, so code escape-hatches don't break the tie either way.

Decision table

What I'd do

Run the one your problems belong to — and know that running both is the standard mature setup, not a failure to decide: Node-RED beside Home Assistant handling the house's events, n8n handling the internet-facing workflow automation, each doing the job it was actually designed for. Combined they idle under a gigabyte, and the alternative — forcing one to impersonate the other — costs more in awkward flows than the second container ever will.