n8n Workflow Optimization and Self-Hosted Migration

Haven Lifestyles publishes a US luxury real-estate magazine. A good part of the operation runs on n8n workflows, and if those stop, the work behind them stops too.

The instance ran on n8n Cloud, on the Enterprise plan. It collapsed every day after a few hours, because too many runs were going in parallel. The team restarted it, it ran for a while, it fell over again. The obvious move was to buy a bigger plan, which means a higher bill and the same problem a few weeks later.

I was brought in to find out why it kept falling over, and then to make it stop.

I spent the first part of the project reading the instance instead of changing it: execution history, which workflows ran when, where memory went, how large the payloads were at each step.

Four things were working together:

Memory limits. The plan capped what a single execution could use, and several workflows sat right at that ceiling on a normal day.

Workflows that had grown too complex. They had been extended over months. At that size you cannot change one branch and still be sure what the other branches do.

Payloads pushed through in one piece. Large jobs were handled as one run instead of batches, so one big input could take the instance down on its own.

No headroom. The setup had nothing left over for a peak. Every volume spike went straight into a crash instead of into a queue.

None of this is visible from the outside. From the outside it just looks like n8n is unstable.

Before touching production I wrote down what needed to change and in which order, and went through it with the client. The plan was mostly about making execution predictable:

Split the oversized workflows into parts that can be reasoned about and changed on their own.

Bound memory per run instead of hoping the ceiling holds.

Process large jobs in batches, so the size of an input no longer decides whether the instance survives it.

Keep the behaviour identical from the client's side. This was a rescue, not a redesign, and the team had to be able to keep working during it.

Doing the refactor first also meant the migration later moved a system I already understood.

On the Cloud plan, concurrency and resources are something you buy. Self-hosted, they are something you set. That was the actual reason for the move, the lower bill came with it.

I set up a private Linux server and put Coolify on top of it to run and manage the n8n container, which keeps deployments and updates simple without a managed platform underneath. The server I hardened before anything production-related went on it: SSH on keys only, no password login, no direct root login, firewall closed except for what the service needs.

Then the workflows moved over, with the concurrency limits and resource settings configured directly on the instance.

Before this, a failed run was noticed when someone found missing output. That is late, and it made every incident feel bigger than it was.

I set up monitoring with Slack and email alerting on failed executions. A run that fails now says so, at the moment it fails, in a channel people already have open.

Haven's team changes workflows with Claude over MCP, so the AI edits the automation directly. That works until the model runs out of context. In a long chat it starts filling the gaps with things that are not true, and in an automation platform a confident wrong change is expensive.

The reason was that every session started from nothing. No written rules, no documentation of how the workflows are actually built, no record of what had been changed last week or why.

So I set up a GitHub repository as the base for that work. It holds the processes, the rules for how the AI is supposed to work, and the documentation of the system itself. Everyone at Haven goes through that repository, which means every person and every AI session starts from the same rules and the same picture of the system. The repository also keeps the history: who changed what, when, and for what reason. Before, that knowledge only existed inside individual chat sessions.

This part was not in the original brief. I added it because a refactor only holds if the way changes get made is under control as well.

Automation: n8n, self-hosted (previously n8n Cloud, Enterprise plan)

Runtime: Docker containers on a private Linux server

Platform management: Coolify for deployment, updates and container lifecycle

Server security: SSH key authentication only, root login disabled, firewall restricted to required ports

Monitoring: alerting on failed runs via Slack and email

Change process: GitHub repository holding the AI working rules, process documentation and system docs, used by the whole team as the single entry point for changes, with a full change history including reasons

AI access: Claude via MCP against the n8n instance, working against the documented rules

Error rate down from up to 12% to 0.1%

Over $1,500 saved per month against the Enterprise Cloud plan

The daily collapse is gone, the instance runs continuously under full production load

Failures are visible when they happen instead of when output goes missing

Workflow changes run through one documented process, with a change history instead of knowledge sitting in separate chat sessions