n8n is Great. But Who Maintains It When the Developer Leaves?

n8n is genuinely one of the best things to happen to mid-sized operations teams in the last five years.

You can wire up Slack, Notion, your CRM, an LLM, a webhook, and a database in a Tuesday afternoon. The graph view is satisfying. The community nodes are wild. Self-hosted means you keep your data. It does what Zapier wishes it did, for a fraction of the cost.

We use it. We love it. We recommend it.

And — here's the part that nobody puts in the LinkedIn post — we've also watched it become an operational landmine in roughly half the companies we work with.

The problem isn't n8n. The problem is the maintenance model.

The Honeymoon

It always starts the same way.

Someone on the ops team — usually the one engineer-ish person, the COO's right hand, the "I'll figure it out" person — discovers n8n. They self-host it on a small VPS. They build a workflow that takes a form submission, enriches it with an LLM, scores it, drops it into the CRM, and pings the sales team in Slack.

It works. It's fast. It's beautiful.

Word spreads. Marketing wants one for their lead routing. Support wants one for ticket triage. Finance wants one for invoice processing. Within six months, your one engineer-ish person has built 40 workflows and is the only human on Earth who knows what any of them do.

This is fine. Until it isn't.

The Moment It Breaks

The moment it breaks is always the same. It's never dramatic. It's mundane.

Option A: The person who built it all takes a vacation. A workflow breaks. Nobody else can fix it because nobody else has ever opened the n8n UI. Operations stalls for two weeks. The COO has to manually re-run lead enrichment in a Google Sheet. Everyone pretends this is fine.

Option B: The person who built it all gets a better offer. They give two weeks' notice. They earnestly try to document things on their last Friday. The document is 18 pages, contains 47 screenshots, and somehow makes the situation worse.

Option C: n8n releases a major version. Half the community nodes are deprecated. The workflows still "run," but they're silently failing in ways nobody notices until the sales team mentions they haven't gotten a lead notification in six days.

Option D — the bad one — the n8n instance crashes at 2 AM. Nobody is on-call. Nobody has set up monitoring. Nobody finds out until Monday morning, three days later, when somebody asks "why hasn't anything been processed since Friday?"

Pick your favorite. They're all real. We've seen all four this year alone.

What "Maintenance" Actually Means

Here's the thing about n8n — and any low-code/no-code automation platform, honestly: it shifts the work from writing code to understanding workflows. It doesn't eliminate the work.

A production n8n setup needs:

• Version control for workflows. "Export to JSON" is not version control. You need a real git workflow, a way to diff changes, a way to roll back. Most n8n installations have none of this.
• Environment separation. Dev, staging, production. Most companies run everything on one box. The first time a "small test" floods the CRM with 4,000 duplicate leads, you learn why.
• Credential management. API keys live in n8n's encrypted store. Who has access? Who rotates them? When the OAuth token expires at 3 AM, who reconnects it?
• Error handling and alerting. A workflow that silently fails is worse than a workflow that doesn't exist. You need real error routes, real alerting, and somebody who actually sees the alerts.
• Performance monitoring. Workflows get slower as data volumes grow. Without monitoring, you find out from a customer complaining about a 40-minute delay.
• Dependency hygiene. Community nodes get abandoned. Self-hosted instances need security patches. The Docker image needs updating. The Postgres database fills up. None of this happens by accident.

If this list reads like "operating a small production service" — that's because that's exactly what it is. n8n didn't eliminate ops. It just made the workflows easier to build, while keeping the operational burden roughly identical.

The Single-Person Failure Mode

Let's name the actual problem: bus factor.

In most mid-sized companies running n8n, the bus factor is one. Exactly one human on the planet can fix things when they break. That human is, simultaneously, your most productive employee and your most catastrophic single point of failure.

When they leave — and they will eventually leave — you have three options:

Option 1: Rebuild from scratch. Estimated cost: 3-6 months of operations chaos, plus the salary of whoever has to learn it from zero, plus the lost productivity of every team that depended on the workflows.

Option 2: Hire a replacement who "knows n8n." Good luck. The labor market for "experienced n8n developers" in DACH is approximately twelve people, half of whom are already employed at companies bigger than yours, and the other half are agencies that charge €1,500 a day.

Option 3: Pretend the old workflows still work and slowly drift back to manual processes. This is what most companies actually do. Six months later they're not really using n8n anymore. They're using a Google Sheet and a prayer.

None of these are great.

What Actually Solves This

The fix isn't "don't use n8n." n8n is genuinely good software. The fix is treating n8n like the production system it is.

Distributed ownership. At least two people should be able to fix every critical workflow. If you can't afford two engineers, you need a partner who can be the second.

Workflow-as-code. Export workflows to JSON, store them in git, treat changes like code reviews. n8n has APIs for this. Almost nobody uses them.

Real monitoring. Uptime checks on the n8n instance itself. Execution logs piped to a real observability tool. Alerts that wake somebody up.

Documentation that survives. Not "here's a Loom video Klaus made before he left." Actual structured runbooks for the workflows that matter. With diagrams. With error scenarios. With escalation paths.

A maintenance budget. Plan for ongoing maintenance equal to roughly 20-30% of the original build cost, every single year. If you didn't budget for this, you don't actually have an automation system. You have a time bomb.

The Uncomfortable Question

Here's the question we'd ask if we were sitting across from you right now:

"If your n8n person quit tomorrow, how long until something important breaks?"

If the answer is "two weeks at most" — good. You're doing it right.

If the answer is "honestly, immediately" — that's not an automation system. That's a hostage situation. You're paying ransom to your own infrastructure, and the ransom is the salary, the patience, and the goodwill of one human being who could leave at any time for any reason.

That's not a sustainable position. It just feels sustainable until the day it isn't.

The Bottom Line

n8n is a great tool. It's also a production system. Treat it like one.

If you can't afford to treat it like one — if you can't justify a second engineer, a real monitoring setup, a proper git workflow, and a maintenance budget — then you have two honest options. Either accept the risk and document it (so your COO knows what they're signing up for), or hand the operational layer to someone whose job it is to keep these things running.

Either is fine. Pretending the problem doesn't exist is not.

The graveyard of abandoned n8n instances is growing fast. Don't add yours to it.

---