EdgeLinkd runs your existing flows.json as a single native binary — with the full Node-RED editor built in, runtime nodes implemented in Rust, and roughly a tenth of Node-RED's memory footprint.
Node-RED made flow-based programming mainstream. EdgeLinkd keeps its editor, its flow format and its message semantics — and replaces the Node.js runtime underneath with native Rust.
| Node-RED | EdgeLinkd | |
|---|---|---|
| Execution | Node.js and V8 — JIT-compiled, garbage-collected | Native Rust on Tokio — no JIT, no garbage collector |
| Scheduling | One JavaScript event loop for the standard runtime | Tokio's multi-threaded scheduler runs independent node tasks across CPU cores |
| Memory | Baseline | ≈ 1/10 of Node-RED |
| JavaScript | Every node is JavaScript | Only inside function nodes, in an embedded QuickJS sandbox |
| Flow format | flows.json | The same flows.json — no conversion step |
| Editor | Node-RED editor | The same editor, served by the binary itself |
| Deployment | Install Node.js, then npm packages | Copy one binary; add --headless for production |
| Extending | npm packages | Rust crates, statically linked through #[flow_node] |
The honest trade-off: third-party npm nodes do not run on EdgeLinkd, and features that do not fit an embedded budget are rejected at deploy time instead of being silently ignored.
Design, deploy and run in the same binary. Everything except the code you write in function nodes is compiled Rust.
Author in the Node-RED editor and deploy the same JSON. Flows, subflows, link nodes, environment variables and JSONata expressions follow Node-RED semantics.
[
{ "id": "f1", "type": "tab", "label": "Sensors" },
{ "id": "n1", "type": "mqtt in", "z": "f1",
"topic": "sensors/+", "wires": [["n2"]] },
{ "id": "n2", "type": "json", "z": "f1",
"wires": [["n3"]] }
]The complete Node-RED editor ships inside the binary: palette, deploy, debug sidebar, import and export. Switch it off with --headless.
Every node is native Rust. function nodes run in an embedded QuickJS sandbox with node, context, flow, global, env and RED.util.
The standard Node-RED runtime is constrained by one JavaScript event loop. EdgeLinkd schedules one task per node across Tokio worker threads, while each node still processes its own messages in order with back-pressure along every wire.
Upstream mocha tests are ported to pytest and run against the Rust engine through a PyO3 module, with test titles matching upstream character for character.
Release builds optimise for size with LTO and stripped symbols, and node families sit behind Cargo features — so a minimal image compiles only what it uses.
[profile.release]
opt-level = "z" # optimise for size
lto = true
codegen-units = 1
strip = true
[features]
default = ["core", "js", "jsonata", "nodes_network",
"nodes_storage", "nodes_parser"]The edgelinkd binary hosts the runtime and the editor side by side. On deploy, flows become a graph of Tokio tasks joined by bounded channels; all I/O happens at the edges of that graph.
Served by edgelinkd; deploys straight to the engine
Unmodified Node-RED flow format
Merged with CLI flags at start-up
src/crates/webcrates/coreruntime/nodes · node-plugins/Self-registered with #[flow_node] and inventory — there is no central node list.
Subscribe and publish to brokers
Endpoints in, requests out
Listeners and clients
Raw sockets, unicast & multicast
file · file in · watch
Run and signal commands
tests/ · crates/pymodNode-RED's mocha specs, ported to pytest, drive the real engine through the edgelink_pymod PyO3 extension on every CI run.
The engine parses flows.json, resolves every node type against the registry and spawns one Tokio task per node, wired through per-port senders.
Every inbox is a bounded channel. A slow consumer slows its producers instead of growing an unbounded queue — memory stays predictable on small devices.
Messages travel as shared Arc<RwLock<Msg>> handles and each node processes them one at a time, preserving Node-RED's ordering guarantees.
JSONata is evaluated in pure Rust; only function nodes enter QuickJS. Everything else on the hot path is compiled code.
EdgeLinkd is a Node-RED compatible runtime, not a clone. Whatever it ships must behave exactly like Node-RED v4.0.9; whatever does not fit an embedded budget is declined — loudly.
For every supported node and option, message semantics, error and status behaviour and the editor contract match upstream.
No silent no-ops, no plausible stubs. Unsupported configuration fails at deploy time or raises NotSupported.
A generated report diffs the ported tests against upstream describe() and it() titles, node by node.
RED.util in the function sandboxSpec-verifiedjsonata-coreIn progressEdgeLinkd builds with stable Rust. Prebuilt beta packages are also published on GitHub Releases.
The pinned Node-RED checkout provides the editor assets and the behavioural reference.
git clone --recursive https://github.com/oldrev/edgelinkd.gitcd edgelinkdRequires Rust 1.88 or later. On Windows, keep Git's patch.exe on PATH and install the MSVC toolchain.
cargo build --releaseStarts the engine and serves the Node-RED editor at http://127.0.0.1:1888.
./target/release/edgelinkd runSame flows, no web server. To reach the editor from another machine instead, pass --bind 0.0.0.0:1888.
./target/release/edgelinkd run ./flows.json --headlessAnywhere Node-RED flows make sense, but a Node.js runtime does not.
Aggregate and filter sensor traffic — MQTT, HTTP, TCP and UDP — right next to the devices, with minimal RAM.
Run control and data-acquisition flows on embedded controllers, with the web editor at hand for maintenance.
Keep smart-home logic on a Raspberry Pi-class board instead of a full Node.js stack.
Move existing Node-RED flows from servers onto devices without rewriting them.
Ship one binary in a small image, with or without the web UI.
Iterate in the built-in editor during development, then deploy the same flows headless in the field.
EdgeLinkd is open source under Apache-2.0 and developed in the open. Try it, report what breaks, or port the next node.