Automation & integration

Most organisations have someone who exports a report on Friday, pastes it into a spreadsheet, renames some files and emails three people. That person is usually very reliable, which is why nobody has noticed what it costs.

This engagement covers those handovers between systems that are currently done by hand, from memory, by one person who then cannot go on holiday.

What it looks like in practice

An issue closed in Redmine files its deliverables into the right Nextcloud folder and notifies the client. A form submission opens a ticket with the right tracker, custom fields and watchers already set. Timesheets roll up into the invoicing export without anyone reconciling them. A contract nearing its end date raises a task ninety days out. A nightly job checks that the things that were supposed to happen did happen, and reports when they did not.

None of this is clever, but together it tends to take up a day a week that never appears in any plan.

How we build it

Node-RED on NixOS with PostgreSQL, declared in your repository like everything else. Flows are exported as JSON and committed to Git, so each automation has an author, a diff and a review. Otherwise it lives only inside a web interface, where somebody changed it last March and cannot remember why.

We run a staging instance against test data, since automation that goes wrong does the wrong thing very quickly. Every workflow alerts on failure. Silent automation is worse than none, because people stop checking.

Some jobs do not suit a canvas: anything with real branching logic, retries with backoff, or a proper data pipeline. For those we write a small Ruby service and schedule it with systemd. A visual editor works well up to a point, and past it a hundred nodes are harder to read than fifty lines of code.

Why Node-RED and not n8n

The obvious choice here is n8n. It is a good product with a nicer editor, and our reasons for not defaulting to it have little to do with features.

n8n is source-available rather than open source. It is published under the Sustainable Use License, which lets you self-host it for internal business use but is not OSI-approved, and files marked .ee require a commercial licence. It is also controlled by a single company.

Node-RED is Apache 2.0 and governed by the OpenJS Foundation. That difference matters because a licence can be changed by whoever controls it. A foundation has no commercial reason to relicense; venture-funded companies do it from time to time. For a tool that will connect your systems for a decade, we value that more than a better node palette.

If you want n8n anyway, we will deploy and run it properly. It is your architecture, and you will have heard this argument first.

There are two other options we rate, depending on the work. Kestra (Apache 2.0) suits orchestration more than glue: retries, backoff and dependencies between jobs, declared as YAML in Git. It has the same single-vendor structure as n8n, though for now the vendor is heading in a good direction. Huginn (MIT, community-run, Rails, so the same stack as your Redmine) fits when the problem is watching rather than glue: polling a source on a schedule and acting when the result changes. Huginn has no site of its own; huginn.sh is an unrelated product under a Business Source License.

Where it falls short

Automating a broken process gives you a faster broken process. If the Friday spreadsheet exists because two departments disagree about who owns something, no workflow will fix that. We will tell you so, rather than build a very efficient way of continuing the argument.