02 Applications we run for you
Node-RED
Flow-based automation under foundation governance — no vendor that can change its mind about the licence.
- Role
- Workflow automation
- Licence
- Apache 2.0
- Since
- 2013
- Upstream
- Project site ↗
Node-RED is a flow-based automation tool: a visual editor for the joins between systems, self-hosted on your own machine.
Why we choose it over the popular alternative
The obvious choice here is n8n, and it is a good product. We do not default to it, for a reason that has little to do with features.
n8n is source-available, published under the Sustainable Use License and controlled by a single company. Node-RED is Apache 2.0 and governed by the OpenJS Foundation. That distinction is the whole argument: a licence is only as durable as the entity that can change it, and a foundation has no commercial reason to relicense while a venture-funded company periodically does.
For a tool that will end up holding the joins between your systems for a decade, that is the property worth optimising for — more than a nicer node palette.
What it is good at
Event-driven glue. A webhook arrives, something happens in Redmine, a file lands in Nextcloud, a nightly job checks that the things that should have happened did. It has been in production use since 2013, originally out of IBM, with a very large library of community nodes and a runtime small enough to run on a Raspberry Pi in a plant room.
Flows are JSON, so they commit and diff like any other artefact — which is the discipline that turns automation from folklore into reviewable infrastructure.
How we run it
On NixOS with PostgreSQL for state, declared in your repository. Flows exported and committed to Git, so every automation has an author, a diff and a review rather than existing only inside a web interface. A staging instance runs against test data, and every flow alerts on failure — silent automation is worse than none, because people stop checking it.
The honest limit
The editor looks its age next to newer tools, and the node ecosystem is uneven: excellent for protocols and hardware, thinner for modern SaaS APIs, where you will write more HTTP requests by hand than n8n would need.
And a canvas is a good tool up to a point. Past roughly a hundred nodes a flow is harder to read than the code it replaced, and error handling in particular is easier to get right in a real language. When we reach that, we write a small Ruby service and schedule it with systemd instead.