The Real Cost of "Free"

You spun up n8n on a VPS because it seemed like the smart move. Open source, full control, no vendor lock-in. The Docker setup took an afternoon, maybe a weekend if you were being careful with Postgres and backups.

Six months later, you're the only person who can fix it when something breaks. You've lost a Sunday to a failed update. You've wondered, more than once, whether the money you're saving is worth the hours you're spending.

This is the pattern we see constantly. Technical founders who absolutely could self-host n8n - and did - but now question whether they should.

The Maintenance Audit Nobody Wants to Do

Here's what self-hosting actually costs in time, based on what we see across our clients:

Monthly recurring tasks: Security patches on the host OS. Checking disk space. Reviewing logs for failed executions. Verifying backup integrity. Monitoring memory usage as workflow count grows.

Quarterly tasks: n8n version updates (and testing that nothing breaks). SSL certificate renewals if you're not using auto-renewal. Dependency updates on the underlying stack.

Unplanned incidents: That workflow that suddenly stops working after an update. The database that fills up faster than expected. The container that crashes at 2am during a critical client workflow.

Conservative estimate? Ten hours per month for someone who knows what they're doing. More if you're learning as you go.

The question isn't whether you can handle this. You clearly can. The question is whether your time is better spent elsewhere.

Hidden Costs That Creep Up

The VPS itself is cheap. But then you need monitoring - because you don't want to discover a failure when a client calls. You need automated backups - because losing workflow data isn't an option. You need a staging environment - because updating production blind is reckless.

Each of these is solvable. Each takes time to set up correctly. Each adds another thing to maintain.

The n8n community puts it bluntly: "The free self-hosted version isn't truly 'free' - you're still paying for hosting infrastructure somewhere, and those costs can actually approach cloud pricing." That's before you factor in your time.

Where Self-Hosting Falls Apart

The failures we see aren't usually dramatic. They're slow bleeds.

Scaling hits a wall. Your single VPS can't handle the execution volume anymore. Now you need to think about queue mode, worker processes, load balancing. The architecture that took an afternoon suddenly needs a redesign.

Security becomes anxiety. A CVE drops for a dependency. You know you should patch it. You also know that patching might break something. It sits in your to-do list, generating low-grade stress.

Recovery time is undefined. When managed services go down, there's an SLA and a team working on it. When your self-hosted instance dies, there's you - and whatever else you had planned for that day.

When Self-Hosting Actually Makes Sense

Not everyone should abandon self-hosting. It's the right choice when:

You need custom nodes that require npm packages not available in cloud environments. AI agents with specific dependencies, internal API integrations, anything that demands deep customization.

Data sovereignty is non-negotiable. Some industries, some clients, some regions - the data simply cannot leave your infrastructure.

You have dedicated DevOps bandwidth. Not "the founder who learned Docker," but actual infrastructure capacity that isn't competing with product work.

Your scale economics flip the math. At massive execution volumes, the cost savings from self-hosting can be substantial. But you need to actually be at that scale, not just planning for it.

The Decision Framework

Stay self-hosted if: You have genuine DevOps capacity, require deep customization, and the maintenance burden isn't competing with growth work.

Move to managed hosting if: You want the control of self-hosting without the maintenance. Fixed costs, automatic updates, someone else handles the 2am alerts.

Hire an expert if: Your self-hosted setup works but you've hit a wall - scaling issues, reliability problems, or simply the realization that your time is worth more than the savings.

The founders who do best with this decision are the ones who honestly audit their time. Not what the setup theoretically costs, but what it's actually costing them in attention and opportunity.

FAQ

Is n8n cloud worth it compared to self-hosting?

For most non-technical teams, yes. For technical founders, it depends entirely on whether you have the bandwidth for ongoing maintenance. Cloud removes the infrastructure burden completely - no servers, no updates, no monitoring. You pay more per month, but you're buying back time.

What's the hardest part of running n8n in production?

Scaling beyond a single instance. n8n works great on one server until it doesn't. Queue mode, worker separation, and database optimization require infrastructure knowledge that most founders didn't sign up for.

Can I migrate from self-hosted to managed later?

Yes, and it's not as painful as you might expect. Workflow exports are straightforward. The main work is in credential migration and ensuring your integrations reconnect properly. Most migrations we do take a day or two.

How do I know if my self-hosted setup needs help?

Warning signs: execution failures increasing, memory usage climbing steadily, backup jobs timing out, or the honest realization that you haven't updated in months because you're afraid something will break.

If you've read this far, you're probably already feeling the maintenance burden. We help technical founders get their n8n setups production-ready - or migrate to infrastructure that doesn't require their constant attention. Talk to n8n Logic about what makes sense for your situation.