A flow engine in Go, in one static binary, with an editor of its own and a scheduler that holds up when a
sensor starts talking faster than the thing reading it. Your flow files stay Node-RED v1 compatible, so
point it at a flows.json and it runs.
It lives at github.com/Embernet-ai/emberwire, and the HotLoop Flow release is coming. It is Apache-2.0 and stays Apache-2.0.
Both runtimes ran in rootless Podman on one box, with the same five-node flow file deployed to each unchanged, driven by the same load generator in the same sitting. Linux, 12 CPUs, the latest Node-RED image, 8 connections, 30 seconds.
| Flow | Node-RED | Ratio | |
|---|---|---|---|
| Image size | 25.1 MB | 717 MB | 29× |
| Memory, idle | 4.8 MB | 54.6 MB | 11× |
| Memory, under load | 12.3 MB | 179.6 MB | 15× |
| Throughput | 3,460 req/s | 1,290 req/s | 2.7× |
| Latency p50 | 1.03 ms | 4.61 ms | 4.5× |
| Latency p99 | 16.72 ms | 23.14 ms | 1.4× |
| Cold start | 2.1–2.3 s | 4.6–5.5 s | ~2.3× |
A benchmark table with no caveats under it is marketing wearing a lab coat. These figures are not allowed to say three things.
Produced by the benchmark command that ships in the repository, so you can disagree with it on your own hardware. The method, the flow file, the exact commands, and the caveats live in the repo's bench docs.
Node-RED puts a setImmediate between every wire hop, and that queue has no ceiling. A fast
source outruns a slow sink, the queue grows, and the pod gets OOM-killed with nothing in the log to explain
it. node-red#855 has been open since 2016.
Every inbox in Flow is bounded, with a policy per node: block, drop the newest, drop the oldest, or raise
it to a Catch node and let the flow decide.
One event loop carries the runtime, the editor API, the websocket fan-out, and every node's I/O. One CPU-heavy Function node stalls all of it, including the editor you are using to find out why it stalled. In Flow, every node instance gets its own goroutine, ordered within a node and parallel across nodes.
That is not our accusation, it is Node's own documentation: “The
node:vm module is not a security mechanism. Do not use it to run untrusted code.”
Node-RED's trust model is that anyone who can deploy a flow already owns the box, which is fine on a Pi in a
workshop and not fine on a customer's plant floor. It is not hypothetical either:
CVE-2025-41656 is unauthenticated remote code
execution against a default Node-RED, reached by deploying a flow with an exec node in it.
They are encrypted with AES-256-CTR keyed by a raw SHA-256 of your secret. CTR has no MAC, so anyone who can write the credentials file on a shared volume can flip chosen plaintext bits, which turns “can write a file” into “can change a broker password to one they picked.” And plain SHA-256 is not a key derivation function. There is no CVE on either of those, and both are still real.
| Node-RED | Flow | |
|---|---|---|
| Runtime | Node.js, one event loop | Go, goroutine per node |
| Back-pressure | None, unbounded queue | Bounded inbox, four policies |
| Message cloning | First recipient aliases the sender | Every recipient gets a copy |
| Function sandbox | node:vm, explicitly not a boundary | goja with no host bindings, plus WASM guests with a hard memory ceiling |
| exec node | Any command, through a shell | Disabled until allowlisted, and no shell at all |
| File nodes | Any path the process can reach | Scoped to the volume, symlinks resolved |
| Credentials | AES-256-CTR, SHA-256 as the key | AES-256-GCM, Argon2id |
| Context API | get, set | get, set, CompareAndSwap, Increment, Update |
| Flow file writes | In place | Temp file, fsync, rename, fsync the directory, three backups deep |
| Config | settings.js, executable JavaScript | Declarative YAML |
| Auth | Off by default | Refuses to start without it |
| Metrics | None | Prometheus, per node |
| Node definition | A .js plus a hand-written .html twin | One Go descriptor |
Flow is deliberately not identical. Node-RED hands the first recipient on a wire the original message and only clones for the rest, so two branches that each believe they own their message can quietly corrupt each other. Every recipient in Flow gets its own copy. That costs 1.4 µs per hop on the author's machine, and a shared path for large binary payloads takes a 1 MB payload from 217 µs down to 341 ns, which is exactly where the copying would have hurt. Every deliberate difference is written down in the compatibility matrix rather than left as a surprise.
A node that is partially compatible and silent about how is worse than one that is obviously absent, because the flow appears to work and quietly does the wrong thing. So a test fails the build if a node does not say what is missing.
Behaves as the Node-RED node of the same type does.
A subset. The notes say exactly which parts are missing.
Deliberately different, and the notes say why.
No Node-RED counterpart.
They are npm packages that need Node.js. There is no version of this where they work.
Any property typed jsonata is refused with an error rather than ignored, because returning the expression text would make a flow look like it works while routing on a literal string.
Verified against real infrastructure and not merely against its own encoders: MQTT, InfluxDB 2.7, and PostgreSQL 16 in Podman. The race detector is clean on every package. And here is what is not done yet, roughly in the order it bothers the author.
A business can run Flow, modify it, and ship it commercially without asking anyone. That is the point, and it is why Flow is not under the Community License the Gateway uses.
