Self-hosting business process automation software like n8n on a Proxmox LXC means zero licence fees but real operational costs show up by month three: upgrades, backups, and 2am pages.
The zero-cost trap
When you spin up n8n in an LXC on Proxmox, the install is stupid easy. You point it at a database, add a few credentials, and suddenly you have workflows running. The licence cost is zero, and that feels like winning. But what you’ve actually done is taken on a production system. The moment a workflow sends a notification that matters, you’re on call. And in a homelab, you’re the only one on call.
That’s the trap. Business process automation software is the kind of thing where the initial setup is trivial but the long-term ownership is not. It’s not like a media server where a crash means you miss an episode. A dead automation means a bill didn’t get paid, a backup didn’t run, or a client didn’t get their report. The stakes are higher than the homelab context suggests.
Upgrades are a second job
n8n moves fast. There’s a new release every few weeks, and some of those releases break things. Not always, but often enough that you can’t just blind-upgrade. In a SaaS tool, the vendor tests the upgrade, rolls it out gradually, and rolls back if something goes wrong. Self-hosting n8n means you are the vendor. You read the changelog, you test on a copy, you cross your fingers, and you fix it when a workflow node changes its API. It’s a goddamn part-time job.
I’ve spent more evenings than I’d like untangling a workflow that worked fine yesterday and broke after an upgrade. The fix is usually small, but finding it means digging through logs and testing nodes one by one. That time doesn’t show up in the zero dollar price tag.
Backups: the part nobody budgets time for
Backing up n8n isn’t just a container snapshot. Well, it can be, but if you restore from a Proxmox snapshot you get a point-in-time copy that may be missing the last few workflow executions or credentials. A proper backup means dumping the database, exporting the workflows, and storing those somewhere else. And then you have to actually test the restore, because a backup you’ve never restored is a wish.
On Proxmox, snapshots and the built-in backup job are fine for disaster recovery, but they won’t protect you from a bad upgrade or a corrupted database. For that you need a layered approach, including immutable backups so that a ransomware hit or a fat-finger deletion can’t take out your automation history. I wrote about what’s actually enforceable on a homelab budget here, and the short version is that you’ll end up with an offsite copy and a retention policy that isn’t just “keep everything forever”.
Storage also creeps. n8n logs every execution, and if you have a busy workflow that runs every five minutes, the database grows. Execution logs, audit trails, and webhook payloads add up. Before you know it, that 20 GB disk you allocated is 80% full and you’re figuring out how to prune old executions without losing what you need for debugging.
When the IO delay hits
n8n is not a heavy application, but it does a lot of small reads and writes to its database. If that database lives on shared storage—say, a TrueNAS NFS share that’s also serving other containers—you can run into IO pressure stalls. I’ve seen exactly that kind of thing on my own Proxmox setup, where an n8n container saturating the NFS share caused IO delays that made other containers unresponsive. The worst part is that it’s intermittent: everything works fine for days, then a big workflow run or a backup job pushes the storage over the edge and the whole box stutters.
I dug into this in a post about isolating LXC limits vs TrueNAS NFS saturation. The takeaway is that you can’t just throw resources at it; you need to understand where the bottleneck is. For n8n, that often means putting its database on local SSD storage rather than network storage, or setting IO limits on the container to stop it from hogging the pipe.
The SaaS pricing model
I haven’t run Zapier or Make myself, so I’m not going to pretend I know what their day-to-day ops feel like. But I have read their pricing pages, and the model is what matters. Zapier charges per task—a task is roughly one action in a workflow, so a simple two-step Zap running a hundred times a month is a hundred tasks (plus polls). Make charges per operation, which is similar but with some nuances around bundles of data. n8n Cloud charges per workflow execution, with different tiers based on volume and features like multi-user or SSO.
The model is more important than the number because it tells you how costs scale. A workflow that seems cheap at fifty runs a month might become painful at fifty thousand. In a homelab, you’re probably not hitting Zapier’s upper tiers, but if you ever scale up, the per-task cost can dwarf the cost of a small VPS or even a dedicated box.
What the SaaS tools buy you is not having to do any of the stuff I just described. No upgrades, no backups, no IO delay debugging. Someone else is on call at 2am. The trade is that you pay a variable cost that grows with usage, and you give up some control. You also can’t easily self-host if you ever decide the monthly bill is too high—your workflows are locked into their platform.
The month-three ledger
Here’s the honest ledger for self-hosting n8n on Proxmox after three months:
- Licence cost: $0.
- Your time: evenings spent on upgrades, testing restores, and reading logs when a workflow silently fails.
- Storage: database growth and backup copies, maybe a few dozen GB if you’re not careful.
- Sleep: at least one 2am page when a webhook stopped firing or a disk filled up.
- Satisfaction: high, if you like tinkering and learning how the sausage is made.
If you enjoy the ops side, that ledger is a bargain. If you just want the automation to work and never think about it again, it’s a terrible deal. The important thing is to go in with your eyes open. The zero-cost licence is marketing; the real price is your attention.
What I’d do differently
If I were starting over, I’d set stricter log retention from day one. n8n has settings for how many executions to keep, and the default is too generous. I’d also automate the backup before adding any critical workflows, and I’d write down the upgrade procedure so I don’t have to remember it at midnight. Small things, but they’d save me several evenings.
I’d also keep the database on local storage, not NFS. The IO delay problem is insidious because it’s intermittent and affects other containers. A separate LXC or VM with its own disk for n8n is a good middle ground.
If you’d rather pay for this
If reading all that made you tired, that’s fair. The obvious paid options are n8n Cloud, Zapier, and Make. n8n Cloud bills per workflow execution, with monthly plans that include a certain number of executions and then per-execution overage or a higher tier. Zapier bills per task, Make bills per operation, and both add per-seat fees for team features. The exact numbers change too often to quote, but the shape of the bill is predictable: you pay a base fee plus a variable fee that scales with how much you run.
For a homelab, I’d say the paid tools are overkill unless you value your time more than the monthly cost. But if you’re running automations for a small business or a side project that actually makes money, the SaaS route starts to look cheap. Not having to be the on-call person is worth real money. The catch is that you’re renting the platform; if you ever want to move, you’re rebuilding your workflows from scratch.
