Automate without your data
leaving your premises.

The question is never “which automation tool”. It is: can your data pass through a service you do not control, and at what volume will you be working in two years?

When the answer is no, or when the volume makes usage-based billing unreasonable, n8n becomes the right tool. It installs on your own infrastructure, it does not bill per operation, and its code is open. In exchange it calls for an available skill, which most organisations do not have in house. That is exactly what we bring.

We do not recommend n8n on principle. We recommend it when the decision points there, and we say the opposite when a hosted platform is enough.

It is the first question, and it is not technical. It is about what you are willing to entrust, and about who will look after the machine.

The three reasons that point towards self-hosting

• The nature of the data. Health records, accounting documents, HR information, data under contractual constraint. When a clause forbids you to let the data leave, the decision is already settled.
• The volume. Hosted platforms bill per operation or per task. A scenario of eight steps triggered two thousand times a month consumes sixteen thousand operations, not two thousand. Past a certain threshold, the subscription becomes comparable to the cost of dedicated infrastructure.
• Reversibility. An n8n scenario belongs to you, exports and reinstalls elsewhere. That is a difference in kind from a platform you cannot leave without rebuilding.

The three reasons to stay on a hosted platform

Nobody in house to watch a server. A low volume, where the subscription costs less than an hour of monthly maintenance. Or a need for very specific connectors, better covered elsewhere.

We say so during framing rather than afterwards. Selling a self-hosted installation to an organisation with nobody to keep it alive is selling one more dependency, not independence.

What self-hosting really involves

A machine to keep up to date, tested backups, monitoring that alerts a human, and a restore procedure somebody has already run at least once. It is not heavy, but it is not nothing, and it never disappears.

That is precisely what we take on when you entrust it to us, and what we document when you want to take it back.

Not every repetitive task deserves an automation. An automation that saves two hours a month and demands one of maintenance is not a gain, it is a transfer of workload.

The calculation we make before building

Three figures, and they are set before the first line of a scenario. How many times a month the task happens. How long it takes each time. And what an error costs when it goes unnoticed.

The third is the one people forget and the one that decides. A rare task whose error is expensive deserves automating before a frequent task with no consequence.

The flows that pay back most, in our experience

• Creating a record from where the information actually arrives: a form, a shared mailbox, a chat channel. As long as somebody has to copy it, somebody will forget.
• Reconciling two tools that do not talk to each other, typically invoicing and sales tracking.
• The follow-up, which is the most hated and worst-performed task because it rests on memory.
• Consolidating a figure that several people each recalculate on their own, with different results.

What we refuse

Automating a process nobody has ever written down. An automation freezes a way of doing things: building it on a vague process amounts to setting the vagueness in stone, and making it harder to correct than before.

Automating a decision that needs human judgement. You can prepare the decision, gather the elements, alert the right person. Taking it in their place produces errors nobody sees go by.

It is the point on which automation projects differ most, and it appears in almost no quote.

An automation always fails, one day

A connected tool changes its interface, a credential expires, a third-party service is unavailable for ten minutes. That is not a pessimistic assumption, it is the normal behaviour of a system depending on other systems.

So the question is not how to avoid failure, it is what happens when it comes. A silent automation that falls over on a Friday evening produces incomplete data all weekend, and nobody discovers it before the client reports it.

Our rule, applied without exception

Every automation touching a client or an invoice raises an alert a human can see, not merely a line in a log nobody opens.

In practice: an alert in the tool that person already opens, with the name of the scenario, what it was doing, and what has to be picked up by hand. An alert that only says “error” is useless.

Recovery, which counts as much as the alert

A flow that fails halfway leaves an intermediate state. So we design the scenarios so that a retry does not produce a duplicate, and so that what has already been done is not done again. It is invisible when all goes well and decisive on the day it breaks.

What we document as a matter of course

Every scenario carries an explicit name, a description of what it does and of what happens if it fails, and the list of tools it touches. Ten minutes during the build, and the difference between an automation that survives a departure and one that dies with it.

We deliver all three, which lets us recommend without a commercial agenda. Here is the decision as we set it out.

What n8n gains

Control of the data, since everything stays with you. Cost at volume, since it does not bill per operation. Reversibility, since the scenarios export. And real flexibility for particular cases, because it accepts writing a little code when that is the shortest path.

What it loses

Getting started takes longer. The connector catalogue is thinner on consumer tools. And above all, it adds infrastructure to look after, which is no small thing for an organisation with no technical skill available.

The tipping point, in practice

As long as the flow reads like a sentence, “when this happens, do that, then that”, all three will do and the simplest wins. As soon as you have to write “unless”, “for each of the items” or “while waiting for”, the visual representation stops being a comfort and becomes a necessity.

We have set out that decision, with billing figures, in our comparison n8n or Make, and the billing mechanics in Make or Zapier. The complete approach, across all tools, is described on the process automation page.

It is the trade-off of self-hosting, and it almost never appears in quotes. An n8n instance is a service exposed on the internet that holds the keys to all your connected tools. Its compromise is not the same as the compromise of a showcase site.

What we put in place as a matter of course

• Restricted access. The admin interface is not open to the whole world, and authentication is strengthened. It is the measure that costs least and that sees off most automated sweeps.
• Segregated credentials. Every connected tool gets a dedicated account with minimum rights, never a director’s administrator account. An automation that reads invoices does not need to be able to delete them.
• Secrets stored in the tool’s vault, never written in clear inside a scenario. A scenario exports, is shared and copied; a credential sitting in it in clear travels with it.
• Tested backups, covering both the scenarios and their execution history. A backup never restored is not a backup, it is an assumption.
• Monitoring that alerts a human when the instance stops responding, not only when a scenario fails.

Updating, which is the real subject over time

Self-hosted software does not update itself, and that is the fundamental difference from a hosted platform. Security patches are applied, or they are not. In the second case the instance goes on working normally, which is exactly the trap: nothing flags the delay, until the day a known vulnerability is exploited.

So we apply a fixed rhythm rather than reacting to alerts, with a test environment before production when the number of scenarios warrants it. A critical patch is the exception and is applied without waiting.

What happens if the instance goes down

Missed triggers do not catch up by themselves. So we design the scenarios so that a retry does not produce a duplicate, and we document what has to be picked up by hand. It is invisible when all goes well and decisive on the day it breaks.

Who carries all this

If nobody is available in house, we carry it, and it is a separate line costed on the number of scenarios in production. If somebody is, we train them and leave them the written procedure. What we refuse is the in-between: an instance handed to a team with neither the time nor the procedure always ends up decaying in silence.

Comparing two automation quotes means nothing until you know what each includes. Here is our breakdown.

What is always included

• The mapping of what really happens, not of what the theoretical process assumes.
• The decision between self-hosting and a platform, in writing, with its consequences.
• The build, the testing, error handling and the alerts.
• The documentation in plain language and training for whoever will take over.

What is costed separately

Hosting the instance, which is in your name and depends on your volume. Subscriptions to the connected tools, for the same reason. And bespoke development, when a business tool offers no standard way to connect.

We take them out of the package deliberately. Including them would allow a rounder price, at the cost of a decision you would never see being made.

Monitoring over time

A self-hosted instance needs somebody watching it. If nobody is available in house, that is part of what we take on, and it is a separate line, costed on the number of scenarios in production rather than as an undifferentiated package.