For years, industrial IoT projects followed a familiar pattern. A cellular router handled connectivity. A separate industrial PC, Raspberry Pi or dedicated gateway ran Node-RED, handled protocol conversion and executed local automation logic. Two boxes, two power supplies, two things to manage.

That architecture is changing.

With Docker support now available on Teltonika’s RUTC-series routers, it is possible to deploy Node-RED directly on the router itself – removing the need for a separate edge computing device in many deployments.

What Is Node-RED?

Node-RED is an open-source visual programming platform originally developed by IBM. Rather than writing traditional application code, engineers build workflows by connecting function blocks together using a browser-based interface.

Each block handles a specific task. Common examples include reading Modbus registers, receiving MQTT messages, calling REST APIs, processing sensor data, generating alerts, triggering actions and writing to databases.

A typical industrial flow might look like this:

1. Read temperature from a Modbus sensor.
2. Compare the reading against a configured threshold.
3. Generate an alarm if the threshold is exceeded.
4. Publish an MQTT message to a cloud platform.
5. Send an SMS notification to a maintenance engineer.

No traditional software development required.

This makes Node-RED particularly popular with systems integrators, BMS engineers and IoT developers who need to build complex automation logic quickly without deep coding knowledge.

Which Teltonika Routers Support Node-RED?

Teltonika does not currently offer Node-RED as a native RutOS package installable via the Package Manager alongside MQTT, Modbus or RMS. However, the three current Docker-capable RUTC models can all run a standard ARM Node-RED container once Docker is installed.

All three RUTC models include eSIM (eUICC) alongside dual physical SIM slots. Docker support is a hardware capability – the RUTC series has the dual-core CPU, 1 GB RAM and 8 GB flash required to run containers. No other Teltonika router series currently supports Docker.

RUTC40, RUTC41 and RUTC50 – What’s the Difference?

For most Node-RED workloads – Modbus polling, MQTT processing, alarm logic, API calls – the RUTC40 has enough headroom. The RUTC50 is the better choice when you need 5G throughput alongside Docker workloads, or where the embedded SIM (eUICC) capability is required for remote SIM provisioning.

How Does Teltonika Compare to Other Routers With Node-RED?

Teltonika is not the only industrial router vendor offering Node-RED at the edge. The approach varies considerably between manufacturers – from native built-in tools to Docker containers to SDK-based app frameworks. Here is how the main options compare.

Milesight UR75 – the closest direct rival

The Milesight UR75 is the most direct comparison to the Teltonika RUTC50. Both are 5G industrial routers with Wi-Fi 6, dual SIM, RS232/RS485 serial ports, and the ability to run Node-RED on the device. The key difference is approach. Milesight builds Node-RED in as a named, marketed feature accessible directly from the router web GUI under APP > Node-RED. Teltonika exposes Docker and lets you deploy Node-RED (or anything else) as a container. Milesight’s approach is lower friction for engineers who just want Node-RED working out of the box. Teltonika’s approach is more flexible for teams who want to run multiple containers or custom applications alongside Node-RED. The UR75 uses a quad-core ARM Cortex-A55 at 2 GHz versus the RUTC50’s dual-core Cortex-A53 at 1.3 GHz, which gives Milesight a processing edge for heavier flows. The RUTC50 counters with eSIM support – the UR75 standard models do not include eUICC.

Robustel R2000 / R3000 – RobustOS app approach

Robustel offers Node-RED as an installable app within RobustOS on its R2000 and R3000 series routers. This is a different architecture to both Teltonika and Milesight – the app runs natively on the OS rather than in a container or through a visual-first toolchain. For straightforward Modbus-to-MQTT type flows it works well. Robustel also produces dedicated edge gateway hardware (the EG5120 and EG5200) running Debian with full Docker support and a pre-installed Node-RED, InfluxDB and Grafana stack – but those are gateways, not routers. For the combination of cellular routing and Node-RED in a single device, the R2000/R3000 series competes directly with the RUTC40 and RUTC41 on price and industrial credentials.

MultiTech Conduit – LoRaWAN gateway, not a cellular router

MultiTech’s Conduit range includes Node-RED via its mPower AEP platform and supports Docker on the Conduit 300 series. However, the Conduit is primarily a LoRaWAN gateway with optional cellular backhaul rather than a cellular router with edge compute. It is the right tool for aggregating LoRa sensor networks, not for replacing a 4G/5G router in a SCADA or building management deployment. Worth knowing about, but not a direct competitor to the RUTC series in most industrial IoT scenarios.

Ericsson Cradlepoint – enterprise wireless WAN, different market

Cradlepoint’s R1900 (5G ruggedised) and E3000 support Docker containers via the NetCloud Container Orchestrator (NCCO), meaning Node-RED can run as a container on the device. The hardware and platform capability is genuine. The difference is market and cost. Cradlepoint targets enterprise Wireless WAN deployments – retail, branch offices, transport – and is sold on mandatory NetCloud subscriptions that significantly increase total cost of ownership. For industrial IoT deployments where RMS, Modbus, DNP3 and serial connectivity matter more than carrier-grade enterprise policy management, Teltonika and Milesight are the practical choices. Cradlepoint is what you encounter when the IT department specifies the router rather than the OT engineer.

What the Architecture Looks Like

The traditional IoT stack for a remote industrial site often looked like this:

With a Docker-capable RUTC router, that collapses to:

One device replaces two. For remote sites where cabinet space, power budgets and maintenance visits are all constrained, that matters.

What Can You Build With It?

Modbus to MQTT Conversion

This is probably the most common use case. Many industrial devices still communicate via Modbus RTU or Modbus TCP. Most cloud platforms expect MQTT. Node-RED bridges that gap natively – polling registers, transforming payloads and publishing to an MQTT broker, which can itself be running as a second Docker container on the same router.

Edge Alarm Management

Instead of streaming raw sensor data to the cloud for processing, Node-RED evaluates conditions locally. A tank level drops below 15%. Node-RED catches it immediately, generates an MQTT alert, sends an email and creates a maintenance ticket – all without a round-trip to a cloud server. This reduces bandwidth consumption and cloud processing costs, and means the alarm fires even during a brief connectivity outage.

Building Management Systems

BMS deployments often need to pull data from HVAC controllers, energy meters, occupancy sensors and alarm panels – each potentially using a different protocol. Node-RED handles the integration layer, normalises the data and pushes a unified feed to a central platform.

EV Charging Infrastructure

Charge point operators need remote diagnostics, meter data collection, status monitoring and alert generation across distributed sites. Node-RED can aggregate and pre-process that data locally before forwarding it upstream, reducing the polling load on the central management platform.

CCTV and Security Monitoring

Node-RED flows can monitor camera health, check network connectivity, trigger alarms and generate maintenance alerts – all at the edge, without requiring a permanent connection to a central server.

Combining Node-RED With MQTT on the Same Device

One of the most useful configurations is running both an MQTT broker (Mosquitto) and Node-RED as Docker containers on the same RUTC router. The router provides cellular connectivity, the MQTT broker handles message distribution, and Node-RED sits between the two – subscribing to sensor topics, applying logic and forwarding processed data to the cloud.

This keeps the full publish-subscribe messaging stack local, which is valuable in environments where connectivity is intermittent or latency to a remote MQTT broker would cause problems. If you are running MQTT on a VPS rather than the router itself, IoT VPS has a practical guide to self-hosted MQTT broker deployment.

Why Edge Processing Matters for Remote Sites

Many industrial deployments operate in locations with imperfect connectivity. Weak cellular signal, temporary outages, high latency and limited data allowances are all common constraints.

Running Node-RED locally addresses several of these at once. Critical decisions happen immediately without a cloud round-trip. Only relevant events and aggregated data are transmitted upstream, reducing data usage. Automation continues even when the WAN connection drops. And response times for local actions drop to milliseconds rather than seconds.

For the cellular connectivity side, the choice of IoT SIM card matters alongside the router. Fixed IP SIMs, multi-network SIMs and roaming-capable SIMs each suit different deployment scenarios – IoT SIMs covers the options in detail.

When You Still Need a Separate Server

A RUTC router is still a router running Docker containers, not a server. Node-RED on a RUTC device works well for lightweight, event-driven workloads. It is not the right platform for:

• Large databases or historian applications
• Machine learning training or AI inference
• Video analytics
• Complex Grafana dashboards with many concurrent users
• Hundreds of simultaneous Node-RED flows
• Enterprise-scale data processing

For those requirements, a VPS running Node-RED as a central hub makes more sense, with the RUTC router acting as an intelligent gateway that pre-filters and forwards data. Running Node-RED on a lightweight cloud VPS is a low-cost way to handle the aggregation layer for multiple remote sites – IoT VPS walks through that setup in detail.

A Note on the RUTC50 and eSIM

The RUTC50 includes embedded SIM (eUICC) support, which is worth considering for large-scale or hard-to-access deployments. Rather than physically swapping SIM cards, you can remotely reprovision connectivity profiles over the air using the SGP.32 IoT eSIM standard. For edge deployments where the router is inside a sealed enclosure or at the top of a mast, that can be a meaningful operational advantage. The eUICC technology underpinning this is now appearing across a growing range of industrial routers and modules.

Final Thoughts

Teltonika routers have always been a strong choice for industrial cellular connectivity. The addition of Docker support on the RUTC series extends that beyond routing and into genuine edge computing territory.

Node-RED running directly on a RUTC40, RUTC41 or RUTC50 is not a gimmick or a workaround. For many industrial deployments, it is a practical way to eliminate a separate gateway device, reduce hardware costs and simplify site installations – while keeping the automation logic close to the devices it controls.

The architecture will not replace a dedicated edge server in every scenario. But for Modbus-to-MQTT conversion, alarm management, protocol bridging and edge filtering, it is a compelling option that is only available on the Docker-capable RUTC series.