Automation & integration

Every organisation has a person who exports a report on Friday, pastes it into a spreadsheet, renames some files, and emails three people. They are usually the most reliable person you have, which is exactly why nobody has noticed the cost.

This engagement is about those joins: the handovers between systems that are currently done by hand, by memory, and by one person who 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. Nightly, a job checks that the things that were supposed to happen actually did — and says so when they did not.

None of it is clever. All of it is the sort of work that quietly consumes a day a week and never appears in any plan.

How we build it

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

There is a staging instance running against test data, because the failure mode of automation is doing the wrong thing very quickly. And every workflow alerts on failure: silent automation is worse than no automation, since people stop checking.

Where a canvas is the wrong shape — anything needing real branching logic, retries with backoff, or a genuine data pipeline — we write a small Ruby service and schedule it with systemd instead. A visual editor is a good tool 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, and it is a good product with a nicer editor. We do not default to it, and the reason has almost nothing to do with features.

n8n is source-available, not open source. It is published under the Sustainable Use License — free to self-host for internal business use, but not OSI-approved, with files marked .ee requiring a commercial licence. More to the point, it is controlled by a single company.

Node-RED is Apache 2.0 and governed by the OpenJS Foundation. That is the distinction that matters: a licence is only as durable as the entity that can change it. A foundation has no commercial reason to relicense; a venture-funded company periodically does. For a tool that will hold the joins between your systems for a decade, that property is worth more than a better node palette.

If you specifically want n8n we will deploy and run it properly — it is your architecture. You will simply have heard this argument first.

Two other options we rate, depending on the shape of the work. Kestra (Apache 2.0) when the job is orchestration rather than glue: real retries, backoff and dependencies between jobs, declared as YAML in Git. Its caveat is the same single-vendor structure as n8n, currently pointed the right way. And Huginn (MIT, community-run, Rails — the same stack as your Redmine) where the problem is watching rather than glue: polling a source on a schedule and acting when the result changes. Note that Huginn has no site of its own; the unrelated huginn.sh is a different product under a Business Source License.

The honest limit

Automation applied to a broken process makes a broken process faster. If the Friday spreadsheet exists because two departments disagree about who owns something, no workflow will fix that, and we will say so rather than build a very efficient way of continuing the argument.