Should a Small Team Self-Host n8n?

Should a small team self-host n8n or use n8n Cloud?

Most small teams should start on n8n Cloud. Self-hosting makes sense only when someone on the team is comfortable running servers, patching them, backing them up, and fixing them at short notice. n8n itself recommends self-hosting for expert users and warns that mistakes can lead to data loss, security issues, and downtime.

n8n has become a popular choice for teams that want more control than Zapier or Make give them. Part of the appeal is that you can run it on your own server. For a cost-conscious founder, that sounds like a free automation platform. It rarely is.

I build and maintain automations for B2B teams, including lead routing, enrichment, and CRM syncs. When a client asks whether to self-host n8n, I treat it as an operations question, not a pricing question. Here is how I work through it.

What does self-hosting n8n actually involve?

Self-hosting means you run n8n on infrastructure you manage. n8n's documentation lists the knowledge this requires: setting up and configuring servers and containers, managing application resources and scaling, securing servers and applications, and configuring n8n. That is a real operations role, not a one-time setup task.

The installation itself is the easy part. Following a guide to run n8n with Docker on a cloud server can take an afternoon. The hard part starts after that, when the server needs updates, the disk fills up, a certificate expires, or a workflow suddenly uses more memory than the machine has.

Every one of those events lands on someone. On n8n Cloud, much of that work belongs to n8n. On a self-hosted setup, it belongs to you, at whatever hour it happens.

Why does n8n recommend Cloud for most people?

Because running production software safely is a skill. n8n's own documentation says that if you are not experienced at managing servers, it recommends n8n Cloud. That is a vendor telling you its free option has real costs. I take that kind of advice seriously, because vendors rarely talk customers out of the cheaper path.

The phrase that matters most is "data loss, security issues, and downtime." Automations in a revenue team touch customer data, CRM records, and email sends. A security gap on an automation server is not a small IT problem. It can expose contact data or let someone trigger workflows you did not intend.

Downtime has a cost too. If your lead routing runs on n8n and the server goes down overnight, new leads may wait hours for an owner. You might not notice until a rep asks why the queue is empty.

When does self-hosting make sense?

Self-hosting makes sense when you have in-house infrastructure skills, strict data residency or security rules that require keeping data on your own servers, or workflow volumes where running your own instance is clearly worth the operational effort. If none of those apply, the control you gain is unlikely to repay the time you spend.

A company with a DevOps engineer already running other services can add n8n to their stack with little extra burden. Monitoring, backups, and patching are already part of their routine. For them, self-hosting is a reasonable extension of work they already do well.

A company in a regulated industry may need data to stay on infrastructure it controls. In that case, self-hosting can be a requirement, not a choice. The right move is to staff it properly rather than treat it as a side task.

What are the hidden costs of self-hosting?

The hidden costs are people time, not server bills. Updates, backups, monitoring, security reviews, and incident response all take hours. Count those hours at a real rate. For a small team, a few hours a month of senior attention often costs more than a cloud subscription, even before any outage.

There is also the cost of knowledge concentration. In many small teams, one person sets up the server and becomes the only one who understands it. When that person leaves or goes on holiday, the automation platform becomes a black box. That risk does not show up on any invoice.

I think about rollback here too. When a self-hosted instance breaks after an update, recovery depends entirely on your backups and your notes. My guide to a rollback plan for an automation that went wrong applies doubly when you also own the server underneath.

How do you decide between n8n, Zapier, and Make first?

Pick the platform by the workflows you need and the people who will maintain them, then pick hosting. n8n suits teams that want code-friendly flexibility. Zapier suits teams that want the simplest setup and a wide app library. Make sits in between with a visual builder. The hosting question only matters once you have chosen n8n.

Some teams choose n8n mainly because self-hosting sounds cheap, then discover their workflows would have been simpler in another tool. That is the wrong order. Start with the work, the skills on your team, and how much you need to customize.

I compared the three for small businesses in Make vs Zapier vs n8n for a small business. If n8n wins on the work itself, then decide where it should run.

Can you start on Cloud and move later?

Yes, and for most small teams that is the sensible path. Start on n8n Cloud, build and stabilize your workflows, and learn what volume and data rules you actually have. If you later hire infrastructure skills or face a hard requirement, plan a move with proper testing, rather than starting self-hosted on day one.

Moving later is easier when workflows are documented. Name each workflow clearly, note what it reads and writes, and keep credentials organized. Those habits pay off wherever the platform runs, and they make any future migration a planned project rather than an emergency.

The worst outcome is starting self-hosted to save money, struggling with operations for months, and then moving to Cloud anyway after an outage. Starting on Cloud skips that detour.

What should a self-hosted setup include at minimum?

If you do self-host, include automated backups you have tested restoring, uptime monitoring with alerts to a real person, a schedule for updates, restricted access to the editor, and written notes on how the server is set up. Anything less turns your automation platform into a single point of failure.

Tested restores matter most. A backup you have never restored is a hope, not a plan. Run a restore test on a schedule so you know it works before you need it.

Also decide who owns the instance. One named person should be responsible, with a second person who knows enough to step in. Automations that run revenue work deserve the same care as any other production system. If a task is risky enough that you hesitate to automate it at all, my note on which revenue tasks should stay manual may help.

What should you do next?

Be honest about who on your team can run servers. If nobody can, start on n8n Cloud. If someone can, estimate the monthly hours for updates, backups, monitoring, and incidents, and compare that cost with a subscription. Choose self-hosting only when skills, rules, or volume clearly justify it.

Whichever you choose, document your workflows and name an owner. The hosting decision matters less than whether someone is responsible for keeping the automations healthy.

If you want help deciding where your automations should run, or building n8n workflows that are easy to maintain, reach out. I build and support automation systems for B2B teams. Let's chat.