Node-RED vs n8n comes up whenever a team wants low-code automation and has both devices and business systems to connect. Both tools let you wire nodes together on a canvas, both can subscribe and publish over MQTT, and both can be self-hosted, yet they were built for different jobs. This comparison explains the difference in execution model, MQTT support, licensing and deployment, and ends with a hybrid pattern that gives each tool the work it does best.
The Core Difference: Message Streams vs Workflow Executions
Node-RED is a long-running process that passes messages between nodes in memory. A message arrives on an mqtt in node, travels through a function, a switch and an mqtt out node, and is gone. There is no per-message bookkeeping. That makes Node-RED very comfortable with continuous streams: a sensor reporting every second, a PLC gateway publishing hundreds of tags, a dashboard updating live. It was created at IBM for IoT wiring and is now an OpenJS Foundation project under the Apache 2.0 licence.
n8n is a workflow automation platform. Each trigger starts an execution: a discrete run of the workflow whose input, output and status can be stored and inspected later. That model is excellent for business processes such as "new form submission, enrich the contact, create a CRM record, post to Slack" because every run is traceable and retryable. It is less natural for high-frequency telemetry, where every MQTT message becoming its own recorded execution adds overhead and fills the execution log. n8n is distributed under its Sustainable Use License, a fair-code licence that allows free self-hosting for internal use but restricts some commercial uses, and it is also offered as a hosted cloud service.
Neither model is better in general. They are optimised for different shapes of work.
Node-RED vs n8n Feature Comparison
| Aspect | Node-RED | n8n |
|---|---|---|
| Origin and focus | IoT and event wiring | Business and SaaS workflow automation |
| Execution model | Continuous in-memory message flow | Discrete executions with stored history |
| MQTT | Core mqtt in and mqtt out nodes, MQTT 3.1.1 and 5, TLS, wildcards, retain, QoS | MQTT node for publishing and MQTT Trigger node for subscribing |
| Industrial protocols | Community nodes for Modbus, OPC UA, S7, serial and more | Not a focus |
| SaaS integrations | Available but fewer, often community maintained | Large catalogue of maintained integrations |
| Custom code | JavaScript function nodes | JavaScript and Python code nodes |
| Dashboards | Node-RED Dashboard 2.0 | Not a dashboard tool |
| Debugging | Live debug sidebar and node status | Execution history with per-node input and output |
| Licence | Apache 2.0 | Sustainable Use License (fair-code) |
| Runs on edge hardware | Commonly on Raspberry Pi and industrial gateways | Usually on a server or in the cloud |
| Hosted option | Several third-party hosts | Official n8n Cloud |
MQTT Support in Detail
For IoT work, MQTT support decides most comparisons.
Node-RED treats MQTT as a first-class citizen. The broker config node supports MQTT 3.1.1 and 5, TLS with custom CAs, client certificates, Last Will, clean or persistent sessions, and MQTT 5 properties such as message expiry, response topic and user properties. The mqtt in node handles + and # wildcards, dynamic subscriptions via control messages, and parsing JSON payloads automatically. The Node-RED MQTT tutorial walks through all of it.
n8n includes an MQTT node to publish messages and an MQTT Trigger node that starts a workflow when a message arrives on a subscribed topic. That covers the essential use cases: react to a device event, or send a command at the end of a business process. What it does not try to be is a stream processor, so you will usually want something in front of it that turns raw telemetry into meaningful, low-frequency events.
Both tools connect to any standards-compliant broker. Pointed at a free public MQTT broker such as broker.connectmq.com on port 1883 with a unique client ID, either one is working in a minute.
Deployment and Operations
| Concern | Node-RED | n8n |
|---|---|---|
| Install | npm install -g node-red, Docker, or a Raspberry Pi script |
Docker or npm; n8n Cloud for hosted |
| Storage | Flow files on disk; context in memory or files | Database for workflows and executions (SQLite by default, Postgres recommended for production) |
| Resource footprint | Small enough for a Raspberry Pi | Heavier, grows with execution history |
| Version control | Projects feature with git | Workflow export and import, source control features in some editions |
| Scaling | Run more instances, split flows by responsibility | Queue mode with workers for higher execution volume |
In practice, Node-RED often runs at the edge, close to machines, while n8n runs centrally next to the business systems it talks to.
When to Choose Node-RED
- You process continuous sensor or machine data and need filtering, aggregation or unit conversion.
- You need industrial protocols such as Modbus or OPC UA alongside MQTT.
- The workflow must run on an edge device or offline-capable gateway.
- You want a local dashboard for operators.
- You care about a permissive open-source licence.
When to Choose n8n
- The workflow is mainly about SaaS tools: CRMs, ticketing, spreadsheets, chat, email marketing.
- You need an auditable history of every run, with retries.
- Non-developers on the business side will maintain the workflow.
- Events are relatively infrequent: alarms, completed batches, maintenance requests.
The Hybrid Pattern: Node-RED at the Edge, n8n for Business Events
The most robust setups use both. Node-RED consumes raw telemetry and publishes compact events; n8n subscribes only to those events and runs business processes. The MQTT broker is the contract between them.
Devices --raw telemetry--> MQTT broker --> Node-RED (filter, aggregate, detect)
Node-RED --events--> MQTT broker --> n8n MQTT Trigger --> CRM / tickets / Slack / sheets
n8n --commands--> MQTT broker --> devices
Here is a Node-RED function node that turns per-second machine counts into one shift-relevant event every five minutes, plus an immediate event when a machine stops:
// Input: connectmq/demo/n8x4w1/line1/press3/count, payload = total parts produced
const PREFIX = "connectmq/demo/n8x4w1/events";
const WINDOW_MS = 5 * 60 * 1000;
const count = Number(msg.payload);
if (isNaN(count)) return null;
const now = Date.now();
const s = context.get("s") || { start: now, first: count, last: count, lastChange: now, stopReported: false };
if (count !== s.last) {
s.lastChange = now;
s.stopReported = false; // machine is producing again
}
s.last = count;
const out = [];
// Stop detection: no new parts for 3 minutes, report once
// (relies on the gateway publishing the counter every few seconds)
if (now - s.lastChange > 3 * 60 * 1000 && !s.stopReported) {
s.stopReported = true;
out.push({ topic: `${PREFIX}/press3/stopped`, payload: { since: new Date(s.lastChange).toISOString() } });
}
// Five-minute production summary
if (now - s.start >= WINDOW_MS) {
// note: msg objects in "out" go to the single output one after another
out.push({
topic: `${PREFIX}/press3/summary`,
payload: { parts: s.last - s.first, from: new Date(s.start).toISOString(), to: new Date(now).toISOString() }
});
s.start = now;
s.first = s.last;
}
context.set("s", s);
return [out];
Wire it to an mqtt out node. In n8n, an MQTT Trigger node subscribed to connectmq/demo/n8x4w1/events/+/stopped can then open a maintenance ticket and notify the shift lead, and a second workflow can write the summaries to a spreadsheet. n8n sees a handful of messages per hour instead of thousands, which keeps its execution history useful.
Test the event side from a terminal while you build the n8n workflow:
mosquitto_pub -h broker.connectmq.com -p 1883 -i n8n-test-n8x4w1 \
-t "connectmq/demo/n8x4w1/events/press3/stopped" -m '{"since":"2026-10-16T08:12:00Z"}'
The same edge-processing idea appears in our guides to Node-RED email alerts and Node-RED with Home Assistant, and the Node-RED function node guide covers context and multiple outputs in more depth.
The Broker in the Middle
Whichever combination you choose, both tools are clients and neither should be the system of record for messages. A dependable broker decouples them: Node-RED can be redeployed without n8n noticing, and n8n can be upgraded without devices losing their connection. ConnectMQ provides that layer as a managed MQTT broker with MQTT 3.1.1 and 5, TLS on 8883 and secure WebSocket on 8084. It does not run workflows or connect to SaaS tools itself; that is precisely the job you hand to Node-RED and n8n, connected as ordinary MQTT clients with their own credentials.
For production, give each tool its own credentials from the portal (YOUR_USERNAME, YOUR_PASSWORD, YOUR_CLIENT_ID), use port 8883 with TLS, and use QoS 1 for event topics so a short reconnect does not lose a stop event.
Connect Node-RED and n8n to ConnectMQ
Sign up at app.connectmq.com for the free Serverless plan, no credit card required, create a broker, and connect Node-RED and n8n with separate credentials. The portal's live topic explorer shows the raw and event topics side by side, which makes it easy to confirm that only the right messages reach your business workflows.
Frequently Asked Questions
Can n8n replace Node-RED for IoT?
For low-frequency device events, n8n's MQTT Trigger works well. For continuous telemetry, edge deployment, dashboards and industrial protocols, Node-RED is the more natural fit.
Does n8n support MQTT?
Yes. n8n has an MQTT node for publishing and an MQTT Trigger node for subscribing, and it can connect to any standard broker, including ConnectMQ, with or without TLS.
Is n8n open source like Node-RED?
Node-RED is open source under Apache 2.0. n8n is source-available under its Sustainable Use License, which permits free self-hosting for internal use but restricts certain commercial uses.
Should Node-RED and n8n talk to each other directly?
It is cleaner to connect them through an MQTT broker. Node-RED publishes events, n8n subscribes, and either can be changed or restarted without breaking the other.



