Self-hosted automation

What self-hosting changes

A hosted automation service bills you per task or per operation, and the bill grows with use. Self-hosting moves that to a fixed cost: a server, running whatever volume it can handle, at the same price whether it is busy or idle.

It also changes where your data sits. Every record that passes through a hosted workflow passes through someone else's infrastructure. Self-hosted, it does not leave yours — which is the deciding factor for anyone handling health, financial or legal information.

And it changes who is responsible when something breaks. That is the part worth thinking hardest about, because it is a permanent duty rather than a one-off setup cost.

The real cost, itemised

The server. A small virtual machine runs a single-instance automation platform comfortably for most workloads. This is the part everyone budgets for, and it is usually the smallest line.

A database. Anything beyond trivial use wants Postgres rather than the default file-based store, either alongside the app or managed.

Backups. Workflow definitions and credentials need backing up somewhere that is not the same server.

Monitoring. Something has to notice when the service stops. An automation that silently fails is worse than no automation, because everyone assumes the work is being done.

Attention. Updates, certificate renewals, disk space, and the occasional breaking change. Not large, but never zero, and it never ends.

What actually goes wrong

In our experience running these for clients, failures cluster into four kinds, and none of them are exotic.

Disk fills up. Execution history grows without limit unless pruning is configured. This is the single most common cause of an instance falling over.

A credential expires. An OAuth token lapses and every workflow touching that service fails at once. It looks like the platform broke; it did not.

A third-party API changes. Someone else ships a breaking change and your workflow stops. Nothing on your side is wrong, and nothing on your side will tell you unless it was built to.

An upgrade changes behaviour. Version pinning and reading release notes prevents this. Automatic updates on a production automation server are a bad trade.

When self-hosting is the right call

High and growing volume, where per-task billing has become the largest line in the tooling budget.

Data that cannot leave your infrastructure, for regulatory or contractual reasons.

Workflows you need to keep. Self-hosted definitions are yours; if the relationship with whoever built them ends, nothing switches off.

Logic the hosted tools handle awkwardly — deep branching, loops over large datasets, or steps that need real code.

When it is the wrong call

Low volume. If a hosted plan costs less than the server, self-hosting is a more expensive way to do the same thing.

No owner. If no one will hold updates and monitoring, the instance will drift out of date and fail at the worst moment. This is the most common reason self-hosting goes badly, and it is a staffing question rather than a technical one.

Urgency. A hosted tool works this afternoon. A self-hosted platform, properly set up with backups and monitoring, takes longer.

How we run it

We deploy n8n on the client's own account, in Docker behind nginx with TLS, backed by Postgres, with execution pruning configured from the start and alerting on both workflow failures and the host itself.

It runs on their infrastructure under their billing, so the workflows and the data remain theirs. If they stop working with us, nothing turns off — which is the point of doing it this way rather than renting them a platform.

Common questions

Which automation platforms can be self-hosted?

n8n is the most widely used, running in Docker under a fair-code licence. Apache Airflow suits scheduled data pipelines, Node-RED suits event and device workflows, and Windmill and Temporal cover code-first orchestration.

How much does self-hosting cost per month?

The server itself is the smallest part — a small virtual machine handles most workloads. Add managed Postgres, offsite backups and monitoring. Budget the maintenance time as the real cost, because that is the line people forget.

Is self-hosted automation more secure?

It gives you control, which is not automatically the same as security. Your data stays on your infrastructure, but patching, access control and credential storage become your responsibility rather than a vendor's.

How much volume can one server handle?

A single modest instance handles tens of thousands of executions a month for typical API-and-database workflows. Heavy data transformation or large file processing hits limits sooner, and n8n supports queue mode with multiple workers for that.

Can you host and manage it for us?

We deploy it on your own account and can keep it monitored, backed up and updated. It stays under your billing and your ownership, so the workflows remain yours whether or not we continue maintaining them.

Can you move back to a hosted service later?

Yes, though workflows are rebuilt rather than transferred, since no automation platform imports another's definitions. The logic is already documented in the workflows, so rebuilding is faster than designing from scratch.