Every Indian team that runs more than a handful of automations eventually asks the same question: do we keep paying n8n Cloud (or Make, or Zapier) by the execution, or do we run our own n8n on a cheap VPS and pocket the difference? As of May 2026, the honest answer is "it depends, and the variables are knowable." This is the cost-and-reliability breakdown we wish someone had handed us before our first self-hosted instance fell over at 2am — VPS sizing, the backup and security work nobody quotes you, and the actual break-even where self-host stops being a hobby and starts being cheaper.
TL;DR — the self-host decision in one paragraph
Self-hosting n8n on a small Indian or India-region VPS costs little in raw infrastructure and saves you from per-execution SaaS pricing that balloons fast. But "free software on a cheap box" hides real labour: backups, upgrades, queue mode for concurrency, monitoring, and security hardening. Self-host wins decisively when you run high execution volume, need data residency, or want unlimited workflows without metering anxiety. SaaS wins when your volume is low, your team has no ops bandwidth, or downtime on an automation would genuinely hurt revenue. Below is how to tell which camp you're in.
Why this question matters more in India (as of May 2026)
Two things make the self-host maths different here than in the US or EU. First, rupee-denominated infra is cheap: a 2 vCPU / 4GB VPS from an India-region provider or a Mumbai-region cloud instance runs a fraction of the dollar-priced SaaS execution tiers, so the gap you're arbitraging is wider. Second, data residency is no longer abstract. With the DPDP Rules notified and 2026 broadly understood as the "build and test" year before substantive obligations land in 2027, more Indian SaaS teams want their automation data — customer records flowing through a workflow, payment webhooks, support tickets — to stay on infra they control and can point an auditor at. Self-hosting n8n inside an India region answers that cleanly. If you're tracking the compliance angle specifically, our DPDP action plan for SaaS founders covers the inventory work that pairs with this.
This is the same trade-off we walk through with clients on our AI automation engagements — and it's a decision Hrishikesh Baidya, our CTO, frames as "buy convenience until convenience costs more than a junior dev-day a month." Below that line, self-host.
The real cost of self-hosting n8n
The sticker price is the VPS. The real price is the VPS plus the work. Let's separate them honestly, because the work is where most "n8n is free!" blog posts quietly lie to you.
Infrastructure costs (the easy part)
| Setup | Spec | Good for |
|---|---|---|
| Starter VPS | 1 vCPU / 2GB / 50GB SSD | Side projects, <1k executions/mo, single editor |
| Production VPS | 2 vCPU / 4GB / 80GB SSD | Real workloads, queue mode off, a few thousand runs |
| Queue-mode setup | 4 vCPU / 8GB + Postgres + Redis | High concurrency, 10k+ runs, multiple workers |
| n8n Cloud (SaaS) | Managed, metered by execution | Zero ops, low-to-medium volume |
Notice the starter VPS undercuts almost everything. That's the trap: the box is cheap, so people assume the project is cheap. It isn't — the box is maybe 30% of the true cost.
The hidden costs nobody quotes you
Add those up and the honest total cost of ownership for a self-hosted production instance is the VPS plus roughly 3–5 hours of someone's time per month once it's stable — more in month one. Value that engineer-time honestly and you've added a real monthly soft cost. That's the number to compare against SaaS, not the bare VPS price.
Reliability: what actually breaks
We've run n8n self-hosted across client and internal projects long enough to know the failure modes. None are exotic; all are avoidable.
The break-even: when self-host actually wins
Strip away ideology and it comes down to three questions. Answer "yes" to any one and self-host is probably right; "no" to all three and stay on SaaS.
We hit exactly this break-even on MereKisan, an agri-tech build where seasonal data-sync workflows spiked hard during sowing windows and the per-execution SaaS bill became unpredictable month to month. Moving the automations to a self-hosted queue-mode instance in an India region flattened the cost and kept the farmer data on infra we could point to. The trade we accepted was the ops work — which, once templated, settled into a few hours a month.
A pragmatic setup checklist
If you've decided to self-host, do these before you put anything load-bearing on it. Skipping any one of them is how "free n8n" turns into a weekend firefight.
- Run n8n in Docker with a pinned version tag — never
latestin production - Use Postgres, not SQLite, the moment you have more than a couple of real workflows
- Put it behind a reverse proxy with TLS; never expose the editor port publicly
- Enable auth (basic auth at minimum, SSO if your team is larger)
- Automate nightly database backups to off-box object storage — and test a restore
- Set the server timezone to IST and verify every scheduled trigger fires correctly
- Add an uptime check plus an execution-failure alert to a channel humans watch
- Configure execution-data pruning so the database doesn't bloat unbounded
- Document the upgrade-and-rollback runbook before your first upgrade, not during
When you should NOT self-host
Three honest cases where paying for SaaS is the smarter rupee.
You have no ops bandwidth. If nobody on the team will own backups, upgrades, and the 2am alert, self-hosting is a liability dressed as a saving. SaaS buys you a team you don't have to hire.
Your volume is genuinely low. A few hundred executions a month? The metered bill is tiny and the engineer-hours you'd spend self-hosting are worth far more elsewhere. Don't optimise a small line item with far costlier labour.
The automation is revenue-critical and you're not ready to engineer for it. If a workflow absolutely must run — settlement reconciliation, a customer-facing webhook — and you can't yet commit to monitoring and queue mode, let SaaS carry the reliability burden until you can.
FAQ
Is self-hosted n8n really free?
The software is open-source and free to run. The infrastructure and the operational labour are not. Budget the VPS plus a few hours of skilled time per month — that total is the real comparison against SaaS, and it's still often cheaper at volume.
SQLite or Postgres?
SQLite for tinkering and tiny workloads; Postgres for anything you'd be upset to lose or anything with concurrent executions. Migrating later is possible but annoying — start on Postgres if you know you're going to production.
How much execution volume justifies self-hosting?
As a rough line, somewhere around 5,000–10,000 monthly executions is where flat-cost self-host typically beats per-execution SaaS, assuming you have the ops bandwidth. Below that, SaaS usually wins on total cost including your time.
What about queue mode — do I need it on day one?
No. Start single-process. Add queue mode (Redis plus workers) only when concurrency spikes cause delayed or failed executions. Premature queue mode is just more moving parts to break.
Can I keep data inside India?
Yes — run the VPS or cloud instance in a Mumbai or Delhi region. This is one of the strongest reasons Indian SaaS teams self-host, especially as DPDP obligations firm up toward 2027.
Want us to size and harden your n8n setup?
We run a fixed-scope n8n self-hosting assessment for Indian teams: a VPS-sizing recommendation against your real execution volume, a security-and-backup hardening pass, and a self-host-vs-SaaS break-even number specific to your workloads. You walk away with a runbook your team can own. Suitable if you're spending steadily on automation SaaS or have data-residency requirements.
Book an Automation Assessment
