n8n Self Hosted vs Cloud: Cost, Control and Limits (2026)

The short answer

If you want to open a browser, build workflows and never think about servers, n8n Cloud is the simpler path. If you want predictable infrastructure cost, no per-execution ceiling set by a plan, full control over where data lives, and the freedom to install anything next to n8n, a self-hosted instance on a VPS is usually the better fit.

Neither choice is permanent. Workflows can be exported and imported, so many people start on one and move to the other once their needs are clear. The rest of this guide covers cost, execution limits, maintenance, privacy and the local versus VPS question, so you can decide with real criteria instead of guesses.

What each option actually is

n8n Cloud is the hosted product run by n8n. You sign up, pick a plan and use the editor. The vendor handles servers, updates, backups and scaling. Plans differ in how many workflow executions you get and which features are included, so the exact limits live on the n8n website and can change. Always read the current pricing page before you decide.

Self-hosted n8n means you run the n8n software yourself, most often in Docker on a server you rent. The community edition is published under n8n's fair-code licence, so read the licence terms on GitHub and the n8n documentation to confirm your use case is covered. Some features are reserved for paid editions, so check the docs for what your edition includes.

A VPS is the usual home for a self-hosted instance. It is a server that stays online around the clock, with its own dedicated IP address. If you are new to the terms, the guide on RDP vs VPS explains how the two server types differ.

Cost: how to compare without guessing

Price tables go out of date quickly, so instead of quoting figures here, use a method that stays accurate. Build the comparison from your own numbers.

Cloud cost is shaped by executions. A workflow that runs on a schedule, on every incoming webhook, or in a loop over many items can consume executions quickly. Estimate how many times each workflow fires, add them up, and compare that total against the allowance of each Cloud plan on the pricing page.

Self-hosted cost is shaped by server resources. You pay for the VPS on a monthly, half-yearly or yearly cycle, and that cost does not change when a workflow runs more often. What changes is whether the server has enough CPU, memory and disk for your load. Your own time also counts: updates, backups and troubleshooting are work you take on.

A fair comparison therefore includes these items:

• The Cloud plan whose execution allowance fits your estimated volume.
• The VPS plan whose resources fit your busiest workflows, plus a margin for growth.
• Your time for maintenance, valued honestly.
• Any features you need that only exist in paid editions of n8n.
• The cost of a reverse proxy, domain name and backup storage if you self-host.

Execution limits and performance

On Cloud, limits come from the plan. When you reach your execution allowance, you either upgrade or wait. That is a clean, predictable rule, but it can push you to redesign workflows to use fewer executions, for example by batching items instead of triggering one run per item.

On a self-hosted instance, n8n itself does not meter your runs in the community edition. The practical ceiling is the hardware. A small server handles light automation well. Heavy workflows that process large files, call many APIs in parallel or keep many executions running at once need more memory and CPU. When one process is no longer enough, n8n supports queue mode with Redis and worker processes, which is covered in the official docs.

Two settings matter early on a VPS:

• Use PostgreSQL instead of the default SQLite database once you have real workloads, so the database copes with many stored executions.
• Enable execution data pruning so old run history does not fill the disk.
• Set the timezone variable so scheduled workflows fire at the hour you expect.
• Choose a server location close to the APIs and users your workflows call, because every round trip adds delay. The 33 server locations make it easier to place n8n near them.

Maintenance effort

This is the real trade-off. On Cloud, maintenance is close to zero. On a VPS, it is yours, but it is a small, repeatable list once the first setup is done.

• Updates: pull the new n8n image and restart the container. Read the release notes first when a version brings breaking changes.
• Backups: back up the database and, critically, your encryption key. Without the encryption key, saved credentials cannot be decrypted after a restore.
• Security: keep the operating system patched, use SSH keys, close unused ports and serve n8n over HTTPS.
• Monitoring: watch disk space and memory, and check that the container restarts after a reboot.
• Recovery: know how to rebuild the server from your backup, and test that at least once.

Data privacy and control

With Cloud, your workflow definitions, credentials and execution data live on infrastructure operated by n8n. That is fine for many teams, but some organisations need to know exactly where data sits or must keep it inside a specific region or network.

With a VPS you pick the location, you hold full root access (or admin access on Windows), and you decide who can reach the server. Credentials, logs and execution history stay on a machine you control. You can also install other tools beside n8n, such as a database, a vector store or a local script runner, and let workflows reach them over a private connection.

A dedicated IPv4 address helps in a practical way. Many third-party services let you allowlist specific IPs. When n8n always calls them from the same address, that rule is easy to set up and easy to audit. Control also means responsibility: you are in charge of patching, access and backups, so privacy only improves if you do that work.

n8n local vs VPS

Some people self-host on a laptop or a home machine. It works for learning and testing, but it breaks down for anything that needs to run reliably.

A laptop sleeps, loses Wi-Fi, restarts for updates and travels with you. Scheduled workflows miss their time, and webhook-based workflows fail while the machine is off. A home connection usually has a changing IP address, and exposing it to the internet means opening ports on your own network, which adds risk.

A VPS removes these problems. It runs 24/7, has a stable public address for webhooks, and does not depend on your own hardware. If you plan to run n8n alongside other agents or tools, the AI agent hosting hub shows how a single server can serve as the always-on base for them.

When each option makes sense

Use the points below as a checklist. Your answers matter more than any general rule.

• Choose n8n Cloud if you want zero server work, run a modest number of workflows, and value support from the vendor over control.
• Choose a self-hosted VPS if execution volume is high or unpredictable, you want cost that tracks server size instead of run count, or you need data kept in a chosen location.
• Choose a VPS if workflows must reach internal services, allowlisted APIs or tools installed on the same machine.
• Start on Cloud, move later if you are still exploring. Export your workflows when you are ready and import them to your own server.
• Stay on your laptop only for experiments that do not need to be online.

How to move to a self-hosted n8n VPS

If you decide to self-host, the setup is straightforward on a Linux server. The page on VPS for n8n covers the use case in more detail, and Linux VPS plans list the available servers. Prefer Windows? See Windows or Linux: which server to rent before choosing.

Here is a practical order of work:

• Pick a server location near the services your workflows call most, then order the plan. Servers are ready in minutes.
• Log in over SSH with root access, create a regular user, and set up SSH keys. Update the system packages.
• Install Docker and Docker Compose. The Docker VPS page and the official Docker site explain the basics.
• Create a compose file for n8n and PostgreSQL. Store the database password and the n8n encryption key in an environment file, and keep a copy of both somewhere safe.
• Point a domain at the server's dedicated IPv4 address, then place a reverse proxy in front of n8n to serve HTTPS. Set the webhook URL variable to your public address.
• Start the stack, open the editor and create the owner account.
• Export your existing workflows from Cloud or your old instance and import them. Re-enter credentials if needed and test each trigger.
• Schedule backups of the database and the encryption key, and test a restore.

A note on Windows servers

n8n runs most smoothly on Linux with Docker, but a Windows RDP server is a valid choice if you also need desktop applications or browser-based automation next to your workflows. The Windows licence is included in Windows prices, and you get full admin access. For that scenario see Windows RDP for AI agents, and how to connect to your RDP server if you are new to remote desktop.

Frequently asked questions