The Cheapest n8n Option on Day One Is Not Always the Cheapest in Month Three
If you are evaluating n8n in 2026, the real pricing question is not just “What does n8n cost?” It is “Which cost model gets more expensive as my workflows become important?”
n8n is a workflow automation platform that lets you connect apps, APIs, databases, webhooks, and AI tools through visual, node-based workflows. You can use n8n as a hosted service, or you can run it yourself on infrastructure you control. That sounds like a simple convenience-versus-control decision. In practice, it is a cost-model decision.
That is exactly why this topic matters to us at Raff. We built a dedicated n8n VM offer because some teams want the freedom of self-hosting without turning deployment into a side project. Once automation becomes part of operations, the conversation changes. The question stops being “Can we automate this?” and becomes “What happens to our cost, control, and risk when this workflow starts running all day?”
That is the lens I want to use here.
In this post, “cloud” means running self-hosted n8n on your own cloud VM. “SaaS” means using n8n’s hosted plans. Both can work. But they behave very differently once your automations stop being experiments and start becoming part of how your team operates.
The First Mistake Is Comparing Only the Subscription Price
Most people start with the obvious numbers.
On n8n’s current pricing page, the hosted Starter plan is listed at 20€ per month billed annually and includes 2.5K workflow executions. The hosted Pro plan is listed at 50€ per month billed annually. n8n also makes it clear that its pricing is based on monthly workflow executions, not per-step billing. That is more understandable than many automation tools, but it is still only one layer of cost.
If you self-host n8n, the software itself can be free to run in Community Edition. Your cost moves away from an execution-based subscription and into infrastructure: the VM, storage, backups, updates, SSL, monitoring, and the time required to keep the instance healthy.
That is why “self-hosted is free” is not a serious cost answer. It removes one pricing model and replaces it with another.
What You Are Really Paying For in Each Model
The cleanest way to think about the decision is this:
- SaaS pricing charges you for managed convenience and platform ownership.
- Self-hosted cloud pricing charges you for infrastructure and operational responsibility.
That sounds obvious, but it changes how you should evaluate cost.
With SaaS, you are paying to avoid infrastructure work. You do not provision a server. You do not handle patching the host. You do not deal with reverse proxies, TLS termination, backup jobs, or resource sizing on day one. You get a smoother start, which has real value.
With self-hosting, you are paying for a machine, not a usage meter. That changes the economics quickly once workflow count, data volume, webhook traffic, or internal integrations grow. It also changes the control boundary. The workflows run on infrastructure you choose, with networking, storage, access, and recovery options you define.
The right question is not “Which one is cheaper?”
The right question is “Which cost model fits the way my automations will behave over the next 6 to 12 months?”
Where SaaS Usually Wins
SaaS is often the right answer earlier than self-hosting advocates like to admit.
If you are still validating whether n8n is useful for your team, the hosted option can be the smarter financial choice even if the long-term unit economics are worse. That is because it removes the operational delay between interest and value.
You do not need to think about server sizing. You do not need to think about backups on day one. You do not need to explain to a teammate why automation broke because the VM ran out of memory or because an update was skipped.
For a solo operator, non-technical team, or early proof of concept, that convenience matters. It is not fake value. It is real time saved.
SaaS is especially attractive when:
- your workflow volume is still low
- your integrations are mostly external SaaS apps
- you do not need special networking or internal database access
- speed to first automation matters more than infrastructure ownership
- your team does not want to operate another service yet
In those situations, the subscription is buying focus.
Where Self-Hosted Cloud Starts to Win
The economics change when automation becomes operational rather than experimental.
This is the inflection point that matters. Once workflows become part of lead handling, support routing, reporting, internal ops, engineering notifications, AI enrichment, or backend orchestration, execution volume usually stops being neat and predictable. Usage grows unevenly. Teams add more triggers. Someone connects a database. Someone adds retries. Someone builds a second workflow that depends on the first one. Suddenly the automation layer is no longer a side tool.
That is where running n8n on your own cloud VM starts making more sense.
On Raff’s n8n product page, the positioning is explicit: your n8n instance is self-hosted, under your control, with no execution limits added by the platform. Raff also highlights 400+ integrations, custom node support, and full data ownership. That is a materially different operating model from paying for hosted workflow execution under a plan threshold.
The other part of the equation is price discipline. Raff’s n8n page currently shows snapshots and backups at $0.05 per GB per month, with the first three backups per VM included free. For teams that are already technical, that is often easier to reason about than a subscription tied to execution thresholds.
That does not mean it is always cheaper in total. It means the bill behaves differently.
The Real Cost of Self-Hosting Is Not the VM. It Is Ownership
This is where people get sloppy.
If you only compare a SaaS fee to a VM fee, the self-hosted side can look like an automatic win. That is incomplete.
The real self-hosting cost includes:
- provisioning and initial setup
- software updates
- backup policy
- SSL and domain setup
- monitoring and alerting
- recovery planning
- whoever gets called when something breaks
If nobody on your team can own those things comfortably, a cheap VM is not actually cheap. It is deferred operational work.
That is why the self-hosted decision is strongest for technical teams, agencies, startups with a builder mindset, and operators who already run adjacent infrastructure. If your team already lives comfortably with Linux VMs, reverse proxies, containers, and backup routines, the marginal cost of running n8n is much lower. If you do not, the hidden cost is not money first. It is interruption.
So the honest framing is this: self-hosted n8n is often cheaper on infrastructure, but only cheaper in total if your team can absorb the ownership model without creating drag.
A More Useful Cost Comparison
Here is the practical version of the decision.
| Scenario | Hosted n8n SaaS | Self-Hosted n8n on a Cloud VM |
|---|---|---|
| Early proof of concept | Usually better | Usually unnecessary |
| Low workflow volume, non-technical owner | Better fit | Adds avoidable ops work |
| Internal tools with database/API access | Limited by hosted model assumptions | Usually stronger fit |
| Growing execution volume | Subscription pressure increases | Infrastructure cost stays easier to model |
| Sensitive data or internal systems | Less control | More control |
| Teams already comfortable with VMs | Convenience still nice | Often better long-term economics |
| Custom nodes or deeper environment control | Limited | Stronger fit |
That is the real cost table, even more than the sticker prices.
A team running five light workflows may rationally prefer the hosted option because the avoided setup time is worth more than the savings. A team running always-on internal automations tied to APIs, queues, databases, and business operations may prefer a VM-based model because the infrastructure cost is steadier while workflow volume grows.
Why This Matters More in 2026
Automation in 2026 is not just “if this, then that.”
Teams are using n8n for AI-assisted workflows, webhook processing, lead qualification, content operations, support handoffs, internal notifications, data sync, and backend task chaining. That means more automations are becoming high-frequency, business-critical, and harder to move once they are embedded into daily operations.
When that happens, the pricing model matters more than it did during experimentation.
n8n’s current pricing already reflects this reality. The company emphasizes that it charges for full workflow executions, not individual steps. That makes the product more predictable than many step-based automation tools. But predictability at the platform level is still different from predictability at the infrastructure level.
A subscription threshold asks, “How much did you run?” A VM model asks, “How much environment do you need?”
Those are not the same question.
For technical teams, the second question often becomes easier to manage over time.
Where Raff Fits in This Decision
Raff is not trying to turn this into an ideological argument about self-hosting. The real goal is to make the self-hosted option practical enough that you can choose it when it genuinely fits.
That is why the n8n product exists as a dedicated offer instead of forcing customers to assemble every piece from scratch. The platform is designed around the idea that some teams want the control of self-hosting without turning setup into a side project. Fast provisioning, NVMe storage, AMD EPYC infrastructure, predictable VM pricing, and low-friction backup options all matter more when the service you are running becomes part of your daily operations.
The business pattern behind this is simple. Teams usually do not move toward self-hosting because they love infrastructure. They move because they want fewer pricing surprises, more control over data, cleaner integration with internal systems, or a deployment model that still makes sense once automation becomes central to the business.
That is the actual decision.
What I Would Recommend
If you are deciding today, I would use this framework.
Choose hosted n8n SaaS if:
- you want the fastest possible start
- your workflow count is still modest
- you do not want infrastructure ownership yet
- your automations live mostly in external SaaS tools
Choose self-hosted n8n on a cloud VM if:
- your workflows are becoming operationally important
- you need database, webhook, or internal service access on your terms
- you want more stable long-term economics than execution-based pricing
- your team is already comfortable operating cloud infrastructure
And if you are in the middle, do not force a philosophical decision too early. Start with the model that reduces friction now, but choose a platform path that does not trap you when usage grows.
That is why I think the best n8n cost conversation is not about “free vs paid.” It is about which ownership model matches the stage your team is actually in.
What This Means for You
If you are evaluating n8n today, do not stop at the subscription page.
Map your likely workflow behavior over the next six months. Estimate how often triggers will fire, whether those automations will touch internal systems, and whether your team wants to own the environment or outsource it. Then compare that to infrastructure cost, not just software cost.
If you want a practical path to the self-hosted side, start with Raff’s n8n VM product and compare it against the broader pricing page. Those two pages tell you the most important part of the story: how the ownership model changes once your automations stop being experiments and start becoming infrastructure.
From where I sit, that is the real pricing conversation. Not whether n8n can automate your work. Whether the cost model still makes sense when the automation starts working.