n8n Self-Hosted vs Cloud: Which Should You Pick in 2026?

What "Self-Hosted" and "Cloud" Actually Mean for n8n

n8n is open-source software — the same code runs whether you're on their cloud or your own server. "Cloud" means n8n Inc. runs that code on their infrastructure and you access your instance via a subdomain like yourname.app.n8n.cloud. They manage the server, the database, the SSL certificate, automatic updates, and daily backups. You log in and build workflows. Nothing on your end to maintain.

"Self-hosted" means you provision a server — a VPS from Hetzner, DigitalOcean, Vultr, or AWS — install n8n there, and run it yourself. The most common setup is Docker: you write a docker-compose.yml, spin up n8n alongside a PostgreSQL database, and point your domain at the server. From that point, n8n runs continuously on your machine, and your workflows execute there. The workflow data — execution logs, credentials, workflow definitions — lives in your database on your server.

There's a third option that some teams overlook: n8n Cloud with a dedicated instance (available on the Power plan and above). This gives you cloud convenience with stronger isolation — your instance doesn't share infrastructure with other customers. It's relevant for teams that want managed hosting but have stricter requirements than the Starter or Grow plans provide. But for the purposes of this comparison, the meaningful divide is managed cloud versus running your own server.

Pricing in Real Numbers: Cloud Plans vs VPS Cost

n8n Cloud has three main tiers as of mid-2026. The Starter plan at $20/month gives you 2,500 workflow executions per month — that's one workflow completing start-to-finish counting as one execution, regardless of how many nodes it passes through. The Grow plan at $50/month covers 10,000 executions. The Power plan at $120/month removes execution caps and is aimed at teams running high-volume automations with many active workflows. Beyond Power, n8n offers Enterprise pricing negotiated per account.

Self-hosting costs what your VPS costs. A Hetzner Cloud CX22 instance (2 vCPU, 4 GB RAM, 40 GB SSD) runs €3.79/month — roughly $4.20 at current exchange rates — and handles several hundred daily executions without breaking a sweat. DigitalOcean's basic 1GB Droplet is $6/month and works for lighter usage. For teams running heavier workflows or needing more memory for AI-intensive automations, a $12/month instance (4 GB RAM) is the typical choice. Add a domain name (~$12/year) and optionally a backup service, and total monthly cost stays under $20 even for a well-set-up instance.

The math above is why the crossover question matters. At 500 executions per month, paying $20 for Cloud instead of setting up a server is an obvious win — the time saved on setup and maintenance is easily worth $15/month. But at 15,000 executions per month, you're comparing $120/month (Cloud Power) to $15/month (self-hosted VPS) — a $105/month difference, or $1,260/year. A developer spending 4 hours per year on server maintenance — a realistic estimate for a stable n8n instance — is "paid" at $315/hour on that math. Almost always worth it.

One nuance: Cloud Starter's 2,500 execution limit can feel tight if you have workflows that trigger on webhooks at variable rates. A Shopify store processing 100 orders per day has workflows triggering 3,000 times per month just from order events — already past Starter. I've seen teams underestimate their execution count at sign-up and hit Grow ($50) within the first month. When building cost estimates, count every scheduled trigger, every webhook, every sub-workflow call — they each consume one execution.

Setup: How Long Does Self-Hosting Actually Take?

The honest answer: 15–30 minutes if you've done anything with Linux servers before, 60–90 minutes if you haven't. The setup process has gotten significantly more straightforward over the past two years — n8n now publishes a one-click DigitalOcean marketplace image that gets you a running instance with SSL in about 10 minutes. But most people running self-hosted use Docker, because it makes updates and migrations cleaner.

The typical Docker-based setup on a fresh Ubuntu VPS looks like this:

The part that trips people up isn't Docker — it's the domain configuration. DNS propagation can take 10–30 minutes, and people sometimes start troubleshooting n8n configuration when the real issue is that their domain hasn't resolved yet. If something isn't working in the first 30 minutes, check whether curl -I https://yourdomain.com returns anything before assuming the problem is in your compose file.

n8n Cloud, by comparison, takes two minutes: sign up at app.n8n.cloud, pick a plan, and your instance is live. No server, no DNS, no Docker. For a team that just wants to start building workflows and has no interest in server management, this gap is real and meaningful. The setup cost of self-hosting is a one-time investment, but it's a cost that some people genuinely don't want to pay.

Maintenance Load: Updates, Backups, Monitoring

This is the most honest part of the self-hosting story. The setup is a one-time event. The ongoing maintenance is a recurring cost that people routinely underestimate — and routinely overestimate, depending on who you ask.

Updates: n8n releases a new version roughly every 2–4 weeks. On Docker, updating is two commands: docker compose pull && docker compose up -d. The whole process takes 2 minutes. I update my self-hosted instance maybe 8–10 times per year when I remember to, skipping minor patch releases and updating at minor version increments. In a year, that's 20 minutes of work. n8n Cloud handles updates automatically — you might notice a new feature appeared without doing anything.

Backups: The thing you absolutely need to set up and then never think about again. On Docker with PostgreSQL, a daily backup script looks like this:

#!/bin/bash
docker exec postgres pg_dump -U n8n n8n | gzip > /backups/n8n_$(date +%Y%m%d).sql.gz
find /backups -name "*.sql.gz" -mtime +30 -delete

Run via cron, this takes 30 seconds to set up and produces daily compressed backups with 30-day retention. Add an rsync to an offsite location (a cheap object storage bucket, a different VPS, your local machine) and you have proper disaster recovery. n8n Cloud on Starter and Grow plans includes automatic daily backups maintained by their team — one less thing to think about.

Monitoring: Without monitoring, a self-hosted n8n instance that went down at 3 AM could stay down for hours before anyone notices. UptimeRobot's free tier checks your instance every 5 minutes and sends an email if it's unreachable. Takes 5 minutes to set up. For anything business-critical, also monitor that your scheduled workflows are actually completing — a workflow that silently fails without triggering the instance going down won't show on uptime monitoring.

Feature Differences Between Hosting Options

At the workflow level, self-hosted and Cloud are the same product. Every node, every trigger type, every integration works the same way. The differences are in team management, collaboration features, and some UI conveniences that n8n has prioritized in their Cloud product.

Two items in the table above are worth expanding. The active workflow limits on Cloud Starter (5 workflows) and Grow (15 workflows) can become binding faster than the execution limits. A team running a modest automation stack — email routing, CRM sync, Slack notifications, data exports, reporting, error alerting — will comfortably hit 15 active workflows before hitting 10,000 executions. This is one of the less-discussed arguments for upgrading to Power or switching to self-hosted: the execution count often isn't the binding constraint.

Custom npm modules in code nodes are significant for anyone building automations that require specialized libraries — PDF parsing, image manipulation, custom cryptography, data science utilities. n8n Cloud sandboxes the code execution environment, which means you're limited to the packages n8n pre-installs. Self-hosted runs in your environment: you can install any npm package, pin specific versions, and use local file system access in code nodes. For workflows that aren't just API-to-API integrations, this flexibility is occasionally decisive.

Data Control, Privacy, and GDPR Compliance

When a workflow runs on n8n Cloud, the execution data — including the actual content of every item that passes through each node — is stored in n8n's database on their infrastructure. For most workflows, this is fine: you trust Stripe's cloud with your payment data, you trust HubSpot's cloud with your CRM data, and n8n's cloud with your automation data isn't meaningfully different. n8n Inc. is a legitimate company with standard data processing agreements and GDPR-compliant EU infrastructure options.

The situation changes when the data flowing through your workflows is genuinely sensitive: medical records, financial transaction details, legal documents, internal HR data, or customer information covered by contractual non-disclosure. I've worked with clients in healthcare and legal services where the workflow data itself — not just the credentials — was subject to strict data handling requirements. In those cases, the question isn't whether n8n's security is good enough; it's whether the contract allows the data to pass through a third-party system at all.

Self-hosting solves this completely. Workflow execution data stays in your PostgreSQL instance on your server in your data center (or on a cloud VPS in a region you control). Your automation pipeline becomes a first-party system. This is the primary driver for self-hosting in regulated industries — not cost, not feature differences, but data residency requirements that simply can't be met with a third-party SaaS.

For GDPR specifically: n8n Cloud offers a Data Processing Agreement (DPA) as standard for EU customers and stores data in EU regions if configured. This satisfies GDPR for most use cases. Where GDPR compliance gets more nuanced is with data minimization requirements — if a workflow processes personal data and logs full execution payloads, you may be storing more personal data than necessary. On self-hosted, you can configure n8n to not save execution data at all (EXECUTIONS_DATA_SAVE_ON_SUCCESS=none), giving you fine-grained control over what gets logged. Cloud plans have similar settings, but they apply to n8n's database rather than one you control.

Performance and Reliability

n8n Cloud is designed to be always available. n8n Inc. operates multiple availability zones, runs with load balancers, and maintains an SLA for paid plans. For most users, Cloud uptime is effectively invisible — you don't think about it because it just works. The platform's status page historically shows 99.9%+ uptime for production infrastructure.

Self-hosted uptime depends on your setup. A single VPS without redundancy will occasionally have a bad day — the hosting provider has a network issue, the kernel panics, Docker decides to be uncooperative at an inopportune moment. Hetzner's infrastructure is extremely reliable (they publish uptime statistics north of 99.95% for their compute fleet), but "the VPS is fine" and "n8n is responding" are two different things, and you're responsible for monitoring the gap.

On performance: self-hosted can actually outperform Cloud for certain workloads because you have a dedicated server with predictable resources rather than sharing infrastructure with other tenants. A $12/month Hetzner CX32 (4 vCPU, 8 GB RAM) handles concurrent workflow executions better than a Cloud Starter account will when n8n is throttling execution concurrency to manage shared infrastructure load. For CPU-intensive workflows — heavy data transformation, running code nodes that process large datasets — a dedicated VPS with more RAM gives you more headroom.

Who Should Pick Which — By Situation

Frequently Asked Questions

Related Articles