What it costs to run n8n yourself

The n8n community edition has no license fee. Running it in production still costs money, and most of that cost is your engineers’ time.

At pilot scale it’s small. One instance, a few workflows, an upgrade when someone has a spare hour. Whoever built it absorbs the work and nobody tracks it.

Production is different. Once real business processes depend on the workflows, keeping the instance running is a job on its own, separate from building anything on it. That work falls into four categories.

Patching

Every security advisory means the same set of tasks. Someone reads it, checks whether your version is affected, tests the patch against your workflows in staging, books an upgrade window, applies it, then checks that nothing downstream broke. We’ve covered the security side of this in who patches your automation platform.

The timing is the part that hurts. The work starts when the advisory is published, not when your sprint has room for it. A quarter with several critical advisories is a quarter where planned work gets pushed back more than once.

Infrastructure

A pilot runs on one instance. Production usually can’t.

Once you pass what a single instance can handle, you move to queue mode: Redis, several workers, and a load balancer in front of them. Plenty of teams run this well. It’s still a distributed system someone has to size, tune, and monitor, and you hit it when your volume crosses the line rather than when it suits you.

Then there’s the smaller work. Certificate renewals, a webhook that stops firing after an update, port conflicts, permission errors. Each one costs an afternoon. Together they take up a real share of an engineer’s month.

Execution data and backups

By default, n8n saves every node’s input and output for every execution, and deletes finished executions after 14 days or once there are 10,000 of them, whichever comes first.

At production volume neither default works. A workflow running once a minute hits 10,000 executions in about a week, so the history you need for debugging is already gone. Raise the limits and the table grows instead, which slows queries and makes backups take longer until someone buys more storage.

Add backup checks and log management on top. Teams underestimate this because none of it is setup work. It repeats every week for as long as the instance runs.

Incidents

n8n includes dedicated support and a response-time SLA on its Enterprise tier. Below that tier, when a production workflow fails outside working hours, whoever is awake searches the community forum for someone who hit the same problem.

This is the hardest of the four to put a number on, because it isn’t hours on a timesheet. It’s the delay between something breaking and someone with context looking at it, plus whatever business process was running through it at the time.

Where this ends up

Add the four together and the answer usually isn’t a budget line. It’s a person.

At some point between the first upgrade that breaks a working workflow and the third emergency fix, running n8n stops fitting around someone’s other work. The team hires for it, moves someone onto it full time, or lets the workflows degrade. Most teams get there without having planned for it, because the cost built up gradually.

On a managed runtime the build stays yours and the operating work moves to the platform.

• Tray patches and upgrades the platform. Advisories stop arriving as unplanned work for your team.
• Tray scales it. There’s no queue architecture for your team to size, tune, or get paged about.
• Retention and backups are managed. No limits to re-tune as your volume changes.
• Every customer gets a support SLA. A contractual response time, not a tier you have to reach.

The operating cost stays a line item instead of becoming a hiring decision.