Node-RED: visual flow editor for IoT, IIoT, and Industry 4.0 with native MQTT support

What is Node-RED?

Node-RED is an open-source platform for flow-based programming, started 2013 by Nick O'Leary and Dave Conway-Jones at IBM Emerging Technology, moved to the OpenJS Foundation in 2016. Its market position is clear: Node-RED is the default for IoT and IIoT applications, for Industry 4.0 scenarios with MQTT, Modbus, OPC-UA, BACnet, and serial interfaces. Where n8n, Make, or Zapier aim at SaaS apps, Node-RED aims at physical devices and sensors.

As of May 2026, Node-RED 4.x is stable; the platform runs as a Node.js application on virtually any hardware – from Raspberry Pi (CHF 50 hardware) through industrial PCs to cloud VMs. This hardware flexibility is a central strength: a flow can run directly on the device producing the sensor data, with a minimal footprint (< 200 MB RAM).

The concept of "Flows" is visual: in the browser editor, nodes (building blocks) are wired by drag-and-drop. As of May 2026, more than 5,000 community nodes are available – via the "Flow Library" and npm. Core nodes cover HTTP, MQTT, WebSockets, TCP, UDP, serial, filesystem; specialised nodes add Modbus (industrial devices), OPC-UA (industrial data servers), KNX (building automation), Z-Wave/Zigbee (smart home), and many cloud APIs.

Commercially Node-RED is Apache 2.0 – fully free, no embedded restrictions. No major cloud vendor runs Node-RED as a managed service (FlowFuse, formerly FlowForge, is the exception: USD 9/month per instance, more for small setups). Self-host is the standard choice – Node-RED installs on a server in 5 minutes with `npm install -g node-red`.

In our stack we see Node-RED less in classic fiduciary work, more at industrial SMEs with machine data and at smart-building projects. A Swiss fiduciary without IoT exposure rarely uses Node-RED directly.

Why it matters

Node-RED is unmatched in the IoT space. No other tool in the workflow comparison list covers MQTT, Modbus, OPC-UA, and serial interfaces as natively. Anyone collecting machine data from industrial controllers, controlling heating via KNX, reading solar inverters, coordinating smart-home devices, or wiring a gas-station pump controller finds the right toolbox in Node-RED.

For SMEs with an industrial angle, three levers are realistic. First – machine data collection. An industrial SME with 20 CNC machines collects thousands of data points daily (uptime, temperature, scrap rate). Node-RED runs on an industrial PC in the plant, speaks via Modbus or OPC-UA to the controllers, writes data to InfluxDB or Postgres, and sends a Slack notification on anomaly.

Second – building automation. An SME with an office building wants central control of heating, ventilation, and lighting. KNX or BACnet devices are addressed via Node-RED, switch times and setpoints defined via a dashboard UI, energy consumption logged. Such setups are productive in Node-RED in 1-2 weeks.

Third – smart home in rental. Anyone operating holiday flats or co-working spaces can control locks, AC, and lights via Node-RED – automatically unlock at check-in, switch off at check-out. Z-Wave, Zigbee, and Matter devices are addressed directly.

For a Swiss fiduciary without IoT exposure, Node-RED is unrealistic – the platform offers no benefits for client workflows. We mention Node-RED here mainly as a comparison reference: anyone landing on a workflow comparison page with IoT in mind will struggle with n8n and needs Node-RED.

The Apache 2.0 license is a clear advantage for industrial embedded use cases. Machine builders can include Node-RED in their products without license concerns. This property has established Node-RED in industry.

How it works

A Node-RED flow is a directed graph of nodes. Each node has inputs, a function (read, transform, write data), and outputs. Flows are built in the browser editor by drag-and-drop; they are stored as a JSON file (flows.json) in the filesystem. In the background, the Node-RED runtime runs in Node.js, executes flows, and routes messages between nodes.

Key node categories: input nodes (MQTT-In, HTTP-In, Inject, File-Watch, Modbus-Read, OPC-UA-Subscribe), output nodes (MQTT-Out, HTTP-Response, Debug, File-Write, Modbus-Write, OPC-UA-Write), function nodes (JavaScript code), switch nodes (branching), change nodes (data transformation), template nodes (string templates), cron nodes (time-based triggers).

Messages between nodes are JavaScript objects with a standard shape (msg.payload, msg.topic, msg.timestamp). The function node allows arbitrary JavaScript with access to msg, external modules (whitelisted in settings), and globals. So Node-RED is a hybrid tool: visual for standard cases, code for custom logic.

A typical IIoT flow: an MQTT-In node subscribes to a topic on a Mosquitto broker (e.g. temperature sensors in a workshop) -> function node parses the payload and filters only values > 80 degrees -> switch node decides per sensor ID which target topic the alarm message goes to -> MQTT-Out node sends to an alarm topic -> in parallel an InfluxDB node stores raw data for reporting. Footprint: 50 MB RAM, runs on a Raspberry Pi.

The dashboard functionality (node-red-dashboard, a community plugin) allows building web dashboards directly in the flow editor: charts, buttons, sliders, gauges are added as nodes, the UI is generated automatically. Very useful for internal operations dashboards in industrial or building setups.

Deployment is simple: a single Node.js process per Node-RED instance, optionally with pm2 or systemd as service wrapper. Scaling happens via several instances with load balancing – Node-RED is not optimised for very high volume, more for continuous moderate load (thousands of messages/second).

Versioning happens via the flows.json file in Git plus the node-red-projects extension offering Git integration in the UI. Multi-user editing is limited – Node-RED targets individual operators or small teams.

Node-RED self-hosted in 5 steps

1. 01Install Node.js 20+ on the server, Node-RED via npm install -g node-red, set up a systemd service wrapper for auto-start.
2. 02Configure the reverse proxy: Nginx or Caddy with TLS in front of Node-RED, HTTP auth or OAuth for the editor (default settings are unauthenticated).
3. 03Install plugins: node-red-dashboard for UI, node-red-contrib-modbus for industry, node-red-contrib-influxdb for time-series DB.
4. 04Build the first flow: MQTT-In or Modbus-Read as trigger, function node for filtering, storage node (InfluxDB/Postgres), MQTT-Out for alarm.
5. 05Backup and versioning: push flows.json regularly to Git, activate the node-red-projects plugin for Git integration in the UI.

When to use Node-RED

Node-RED is the right choice when (a) IoT or IIoT protocols (MQTT, Modbus, OPC-UA, KNX, BACnet) are needed, (b) the platform must run on embedded hardware (Raspberry Pi, industrial PC), (c) a visual editor for operations staff makes sense, and (d) workflow complexity stays moderate.

Concrete cases: machine data collection from CNC or PLC controllers, sensor data collection in smart buildings, KNX building automation (lighting, heating, ventilation), smart-home control in holiday flats or hotels, gas-station and charging-station wiring, solar inverter monitoring, water sensors in industry.

For industrial SMEs with a machine park, Node-RED is often the fastest path to a data platform. Low hardware cost (Raspberry Pi 5 for CHF 100), free software, setup time of a week for a first pilot. Data lands in InfluxDB or Postgres, dashboards run on Grafana – a classic IIoT pipeline.

For building-management setups in larger office buildings, hotels, or industrial properties, Node-RED is an established choice. The KNX and BACnet connectors are mature, the system has been running for over 10 years in countless commercial installations.

For a Swiss fiduciary with industrial clients (e.g. fiduciary with IIoT consulting in portfolio), building Node-RED knowledge as a bonus service pays off: machine data collection for reporting and tax optimisation (e.g. investment deduction for digital infrastructure) is increasingly requested.

When not to use

Node-RED is the wrong choice for pure SaaS workflow automation. Client mail triage, lead routing, CRM synchronisation, marketing funnels – these are not Node-RED problems. n8n, Make, Zapier, or Activepieces are more productive there, with a larger SaaS connector catalogue and better multi-user features.

Unsuited for very complex workflows with many sub-workflows, versioning, and code-review processes. The flows.json architecture targets individual operators or small teams. At 50+ production flows with several editors, the platform becomes unwieldy – n8n, Windmill, or Temporal are better structured.

Does not fit high-volume processing in the millions-of-events-per-hour range. The single-process Node.js architecture scales to thousands of messages/second; for more, Kafka, Apache Flink, or dedicated streaming platforms are needed.

For bookkeeping and fiduciary workflows, Node-RED is unsuited. There are no ready-made connectors for Bexio, Abacus, or Lexoffice; the SaaS connector library targets cloud APIs, not bookkeeping-specific software. Anyone building a VAT recognition workflow is more productive with n8n.

For mission-critical data pipelines with complex state and guaranteed exactly-once semantics, Temporal is the more robust choice. Node-RED has no durable execution – a crash can lose messages depending on the persistence strategy.

For multi-tenant SaaS setups (one instance for many customers with isolation), Node-RED is not built. One instance per customer is feasible (FlowFuse does that), but the multi-tenant architecture is not native.

Trade-offs

FAQ

Related topics

Sources

1. Node-RED documentation – nodes, flows, dashboard · 2026-05
2. Node-RED Flow Library – community nodes · 2026-05
3. Node-RED on GitHub – Apache 2.0 source · 2026-05
4. FlowFuse – managed Node-RED service · 2026-04