How much does self-hosted n8n really cost? The complete TCO breakdown

"n8n is free to self-host": the sentence is true, and yet it doesn't answer the question every team asks when comparing n8n Cloud with a self-hosted instance. The cost of software is never just its license — it includes the server, the domain, the backups, and above all the hours spent keeping all of it alive. This article lays out the complete TCO (Total Cost of Ownership) calculation for a self-hosted n8n, with no invented figures: explicit orders of magnitude for what can be priced, and a method for estimating the rest. If you're still weighing the two models on non-financial criteria, our self-hosted vs Cloud comparison complements this analysis.

The license: fair-code, free, with no execution limit

n8n is distributed under a fair-code license (Sustainable Use License). Concretely, for internal use — automating your own processes or your company's, even for commercial purposes — the self-hosted installation costs nothing in licensing, and above all imposes no limit on the number of workflow executions. That's the structural difference with most automation platforms, whose billing grows with operation volume.

Two honest caveats:

• The license restricts reselling n8n as a service to third parties (you cannot host n8n and bill it as a product without a commercial agreement).
• Some features aimed at larger organizations (advanced SSO, granular access control, environments) belong to paid offerings, including on self-hosted.

For n8n Cloud pricing, which changes regularly, the only reliable source is the official n8n.io/pricing page — any figure copied into a blog post would be stale within months. Just keep the principle in mind: the Cloud charges a subscription tied notably to execution volume, while self-hosting shifts the cost toward infrastructure and human time.

The visible cost lines of self-hosting

The server

An n8n instance for a small team runs comfortably on a VPS with 2 vCPUs and 4 GB of RAM. As an order of magnitude — and only as an order of magnitude, since prices vary by provider, region and promotions — count from a few euros to around twenty euros per month. Sizing mostly depends on your workflows: those handling large binary files or many parallel AI calls consume more memory than classic data syncs.

The domain name and HTTPS

A domain name typically costs around ten euros per year. The TLS certificate is free via Let's Encrypt once you put a reverse proxy in front of n8n — our HTTPS with Traefik or Caddy guide covers the setup. This line item is financially negligible but mandatory: webhooks and OAuth integrations require a clean HTTPS URL.

Backups and storage

An instance without a tested backup is an instance on borrowed time. You need to budget for:

• external storage for PostgreSQL dumps and the credentials encryption key (an object bucket or a second server — a few euros per month as an order of magnitude for volumes of this kind);
• the time to set up and test the restore procedure, detailed in our PostgreSQL backup and restore guide.

Redis, if you move to queue mode

As long as the instance stays in single-process execution, no extra component is required. If volume grows to the point of switching to queue mode with Redis (a main instance, workers, Redis as the queue), add the cost of a Redis — modest if it shares the server, a bit more if managed — and above all the operational complexity of one more component to monitor.

The hidden cost: human time

This is the line item comparisons forget, yet it dominates the TCO in most cases. A self-hosted instance requires, on a recurring basis:

• Updates: n8n releases frequently; letting an instance age for months exposes you to patched vulnerabilities and makes version upgrades riskier.
• Monitoring: instance uptime (a Schedule Trigger missed during an outage is not caught up), disk space, growth of the executions database.
• Security: server hardening, access management, protecting your API credentials — the n8n encryption key is a critical asset to back up separately.
• Restores: the day the disk dies, the difference between two hours and two days of downtime comes down to procedures tested in advance.

A reasonable order of magnitude for a well-tooled small-team instance: a few hours per month at cruising speed, more in the first months and during incidents. Value those hours at your organization's fully loaded cost for a technical profile and compare: that's often where the Cloud becomes competitive again — not on the price of the VPS.

This trade-off is nothing new. The reference paper on cloud economics, published in 2010 in Communications of the ACM (Armbrust et al., "A View of Cloud Computing" — Google Scholar), already formalized the terms of the choice: the cloud converts capital expenses into usage-based expenses, transfers operational risk to the provider and offers an elasticity that owned infrastructure cannot match — but becomes less advantageous when the load is stable, high and predictable. Applied to n8n: a massive, steady execution volume argues for self-hosting; a low or uncertain load, for the Cloud.

When each model wins

Self-hosting wins when:

• execution volume is high — the absence of a cap changes the equation as soon as workflows run continuously, for instance to log every AI call as in our guide on tracking AI call costs;
• data is sensitive: customer emails, contractual documents, personal data subject to GDPR, with a requirement for full control over hosting and location;
• infrastructure skills already exist in the team, and the few monthly maintenance hours fit into an existing role rather than creating one.

The Cloud wins when:

• nobody on the team can (or wants to) administer a server — a TCO that relies on hours nobody has isn't a TCO, it's a deferred outage;
• volume is low or irregular: a few hundred executions per month don't justify carrying infrastructure;
• time-to-value comes first: a Cloud account is operational in minutes, while a proper self-hosted setup (HTTPS, backups, monitoring) takes days.

The decision grid

Answer these four questions in order:

1. Can your data leave your infrastructure? If not (strong GDPR constraints, regulated sector), self-hosting is a given — the rest of the grid only serves to size the effort.
2. Do you have server skills available in-house? If not, stay on the Cloud, at least to start: migrating to self-hosted remains possible later, since workflows export cleanly.
3. Does your execution volume durably exceed the Cloud plan tiers? Compare your projection with the official pricing: if the required subscription exceeds the server cost plus your valued maintenance hours, self-hosting becomes rational.
4. Is the automation business-critical? If yes and you go self-hosted, budget for monitoring and backups from day one, not after the first incident.

The honest conclusion: for many small teams, the Cloud is the right starting point, and self-hosting becomes cost-effective with volume, data sensitivity or infrastructure already in place — rarely to save three euros on a VPS.

What this changes for your workflows

The good news: this hosting choice doesn't lock in your workflows. An n8n workflow exports as JSON and runs identically on Cloud or self-hosted — that's the case for all FlowKit workflows, like the email triage in the Inbox AI Pack (€79) or the complete RAG pipeline in the RAG Assistant Pack (€119), delivered as importable JSON on either infrastructure. Start where your team is effective today; the TCO gets recalculated every year, and migration always stays open.