Skip to content
Proxus 2.0.0 Proxus 2.0: the largest release in Proxus history Release notes

Comparison · Node-RED

Proxus and Node-RED are not the same kind of thing.

Node-RED is a flow-based programming tool: you wire nodes together and deploy the flow. It is free, it runs anywhere Node.js runs, and it is the fastest way to prove an idea. Proxus is a product with a fixed operating model: modelling, governance, retention and delivery are features rather than flows you build and own.

What it is
Node-RED: Flow-based programming tool, from OpenJS Foundation
What Proxus is
An industrial data platform: collect, model, govern, store, deliver
Honest summary
Free, fast to prototype, enormous community. A toolkit rather than a governed platform.
Your options
Keep Node-RED where it does its job and add Proxus beside it, or move the job into Proxus. Both paths are below.

Give them their due

What Node-RED is genuinely good at.

A comparison that only lists the other product's weaknesses is a sales sheet, not a decision aid. These are real strengths, and some of them are reasons not to buy Proxus.

  • Nothing gets to an idea faster

    Wiring an MQTT topic to a database in a browser editor takes minutes. For proving that a signal exists and is useful, Node-RED is hard to beat and costs nothing.

  • Over five thousand community nodes and flows

    By the project’s own count on nodered.org (checked October 2026). If something has an API, someone has probably already written a node for it, a breadth no commercial connector library matches.

  • Free and open source, with a real community

    An OpenJS Foundation project with an active ecosystem. There is no licence conversation, and no vendor to wait for.

  • Runs anywhere

    A Raspberry Pi at a machine, a plant server, a cloud VM. The runtime is light and the deployment is trivial.

  • Commercial wrappers exist

    FlowFuse adds fleet management, team access control and commercial support around Node-RED. If you are comparing against FlowFuse, the rows below that say “plain Node-RED” narrow.

Attribute by attribute

Where the two actually differ.

Both columns are filled in. Where Node-RED is ahead, the row says so.

  • What it is

    Proxus

    A product with a defined operating model: sources, models, rules, targets and roles are configuration objects.

    Node-RED

    A programming tool. What it does is whatever the flow you built does.

  • Industrial protocols

    Proxus

    Native drivers for 66 protocols across 30 vendor and standard families, maintained as part of the product.

    In the docs: Industrial protocols

    Node-RED

    Through community nodes, which vary in maintenance and depth. Serious PLC coverage often means paid nodes or custom work.

  • Data model

    Proxus

    A modelled namespace with units, quality and asset context, and an audit trail of configuration changes.

    In the docs: Data model

    Node-RED

    Whatever your flows agree on. Structure lives in the flows and in the heads of the people who wrote them.

  • Reliability during outages

    Proxus

    Edge buffering for the hub and every outbound target, written in order on reconnect, with delivery status per target, as product behaviour.

    In the docs: Reliability during outages

    Node-RED

    Store-and-forward is something you design, build and test yourself.

  • Access control

    Proxus

    Users, roles and object-level permissions, including permissions on namespace paths, applied to people, integrations and AI clients alike.

    In the docs: Access control

    Node-RED

    Plain Node-RED: editor-level authentication, and fine-grained, per-signal permissions are not the model. FlowFuse adds team roles around the editor.

  • History and retention

    Proxus

    Built-in telemetry historian with configurable retention and query access.

    In the docs: History and retention

    Node-RED

    Whatever database you wire up, with retention you manage yourself.

  • Where configuration lives

    Proxus

    On the hub. Gateways keep no configuration of their own and receive it from the hub when they connect.

    In the docs: Where configuration lives

    Node-RED

    On each box, as flows. Backing them up and keeping twenty boxes identical is a process you run.

  • Running twenty sites

    Proxus

    Templates and a fleet of gateways with central visibility, deployed from a documented pattern.

    In the docs: Running twenty sites

    Node-RED

    Plain Node-RED: twenty flow deployments to version, update and keep consistent, solved by your own team. FlowFuse adds fleet management for this.

  • Runtime and dependencies

    Proxus

    One gateway process with the drivers built in and versioned with the release, plus a messaging container for the local buffer. No package manager at the edge.

    Node-RED

    A Node.js runtime plus the npm dependency tree of every node you install. Keeping that current at the edge is your job.

  • What has to be installed at a site

    Proxus

    The gateway process and a messaging container next to it, installed by one script. It carries its own MQTT broker and needs no database at the edge.

    In the docs: What has to be installed at a site

    Node-RED

    Node.js, Node-RED, the nodes a flow needs, and usually a database and a broker alongside it.

  • Execution model

    Proxus

    An actor-based runtime built on .NET, with binary internal messaging.

    Node-RED

    JavaScript on a single-threaded event loop, which is efficient for I/O and a constraint for heavy per-message work.

  • Support and accountability

    Proxus

    A vendor, a release cadence with written notes, and ISO 27001 and ISO 9001 certified processes behind it.

    Certificates: Support and accountability

    Node-RED

    Plain Node-RED: community support, and the person who wrote the flow is the support contract. FlowFuse offers commercial support.

  • Cost

    Proxus

    Licensed per gateway and data rate, with published recommended prices from $5,500 a year.

    Pricing: Cost

    Node-RED

    Free software. The cost is engineering time and the maintenance it accumulates.

Proxus figures come from the current build's own driver and target inventory. Node-RED figures come from the vendor's published material, linked at the end of this page. Nothing here is measured on a benchmark neither party has agreed to.

Choose Node-RED

When we are not the answer.

  • You are proving whether a signal exists and whether anyone will use it. Do not buy a platform for that.
  • One site, one integration, and an engineer who enjoys owning it.
  • You need a connector for something unusual that no commercial product covers, and a community node already exists.
  • Budget is genuinely zero and the risk of a hand-built pipeline is understood and accepted.

Choose Proxus

When the shape of the problem fits.

  • Flows built for a proof of concept are now load-bearing, and nobody wants to be the person who maintains them.
  • More than one site, and the same model has to hold across all of them.
  • A security review is coming, and "the flow runs on a PC under the desk" is not an answer.
  • Data handling has to be provable: operational logs per gateway and an audit trail of configuration changes.
  • The edge box should run one thing you can update as a unit, not a runtime plus a dependency tree per site.

Not either/or

How they are used together.

  • Node-RED at the edge, Proxus as the backbone

    Keep Node-RED for the odd device or the experiment, publish its output to MQTT, and let Proxus model and deliver it with everything else.

  • Prototype there, productionise here

    A flow is a good way to discover what a signal means. Once it matters, the same logic belongs in a pipeline with revisions you can compare, or in a rule or C# function governed by the platform.

  • Consume from Proxus

    Node-RED can read from the Proxus API or subscribe to the namespace when Proxus publishes it to an MQTT broker, which keeps it useful without making it the system of record.

Sources

Last checked against vendor material: October 2026.

Products change. If something on this page is out of date or wrong, tell us and we will fix it, including when the correction favours Node-RED.

Questions

Proxus and Node-RED: short answers.

Can we keep Node-RED next to Proxus?
Yes. Keep it for the odd device or the experiment and publish its output to MQTT; Proxus models and delivers it with everything else. Node-RED can also read from the Proxus API.
What happens to data when the network drops?
Proxus buffers at the edge for the hub and every outbound target, writes in order on reconnect and shows delivery status per target. In plain Node-RED, store-and-forward is something you design, build and test yourself.
What has to be installed at a site?
The Proxus gateway process and a messaging container next to it, installed by one script. It carries its own MQTT broker and needs no database at the edge.

Next step

Move the flows that matter into something supported.

Tell us which flows your plant now depends on and how many sites run them. In thirty minutes we show which become pipelines, rules or C# functions in Proxus, and which are fine where they are.

  1. 01

    Scoping call

    Equipment, protocols, sites and the systems the data has to reach.

  2. 02

    Technical walkthrough

    A working demo against a scenario that resembles your plant, not a generic tour.

  3. 03

    Pilot plan

    A defined first line or site, with the deployment and security questions answered up front.

  4. 04

    Roll-out

    The same templates bring the next lines and sites online.