n8n: Part 2 — Cloud Version or Self-Hosted Server

n8n can be used in two ways: subscribe to the developers’ cloud service n8n Cloud or install the platform on your own server. Workflows and nodes are the same in both cases; what differs are the price, responsibility for system operation, available features, and where the data is stored.

n8n Cloud: what’s included in the subscription

In the cloud version the developers themselves are responsible for servers, updates, backups and availability. You just need to register, choose a plan and start building workflows.

Rates as of September 2026 for annual payment:

Price depends on the number of workflow executions, not on the number of users or workflows. One execution is a single run of a workflow in its entirety, regardless of how many nodes it contains.

What is important for a Russian company to consider:

• Payment. You cannot pay the subscription with a Russian bank card: Visa and Mastercard have not been servicing Russian cards abroad since March 2022.
• Data location. n8n Cloud runs on Microsoft Azure, data is stored in the European Union on servers in Frankfurt. If workflows process personal data of Russian citizens — names, phone numbers, email addresses of customers — the requirement of Federal Law 152-FZ on localization applies: primary collection and storage of such data must be carried out in databases located on the territory of Russia. The cloud version is not suitable for such workflows.
• Execution limits. A workflow that triggers every minute consumes about 43,000 executions per month — more than included in the Business plan. Frequent schedule-based checks quickly exhaust the quota.

Self-hosting: Community Edition and paid editions

Community Edition — the free edition for self-hosting. There are no limits on the number of executions or workflows; these are determined only by server capacity. Scaling via queue and separate workers (queue mode) is also available for free.

According to n8n documentation, Community Edition lacks:

• shared access to workflows and credentials between users and projects;
• SSO (SAML, LDAP);
• development environments and storing workflows in Git;
• variables, external secrets storage, and external storage for binary data;
• log forwarding to external systems;
• multiple main instances (multi-main) for high availability.

Free registration of Community Edition unlocks workflow folders, editor debugging on past run data, and saving your own execution data. Business and Enterprise features are also available for self-hosting, but under a paid license.

For a small company where one or two people manage workflows, Community Edition is usually sufficient. If a team works on workflows and shared access is needed, you’ll either have to agree on a shared account or buy a license.

What server is needed

n8n documentation does not provide fixed hardware requirements: they depend on the volume of data in workflows, the number of nodes and the frequency of executions. The developers note that n8n is more memory-hungry than CPU-hungry. The biggest memory consumers are large JSON responses, binary files, code nodes and manual runs from the editor — for these n8n makes a copy of data for the interface.

For a small single-company installation it makes sense to start with two cores and 2–4 GB of RAM. Such a virtual server from Russian providers costs around a thousand rubles per month: for example, in Timeweb Cloud the Cloud-50 plan (2 vCPU, 4 GB RAM, 50 GB disk) in September 2026 costs 1,080 ₽ per month with annual payment.

The server will need:

• PostgreSQL for storing workflows, credentials and execution history. SQLite is only suitable for getting started; MySQL and MariaDB are no longer supported as n8n databases — they were removed in version 2.0. You can still work with these DBMSs from workflows via the MySQL node.
• A domain and HTTPS so external services can send data to webhooks.
• A reverse proxy in front of n8n: nginx, Caddy or HAProxy. An installation example with HAProxy is in the article Installing n8n in Docker with HAProxy: A Clear Guide for Beginners, on the FastPanel control panel — in the article Installing n8n on FastPanel with Docker Compose: A Clear Guide.

When one server is not enough: queue mode

In normal mode one n8n process both receives webhooks and executes workflows. When the number of executions grows, n8n is switched to queue mode:

• the main instance receives webhooks and scheduled triggers, creates an execution and puts it into a Redis queue;
• workers pick up executions from the queue and run them; by default each worker runs up to 10 executions concurrently;
• with a high flow of webhooks their reception can be moved to separate processes (webhook processors).

The mode is enabled with the variable EXECUTIONS_MODE=queue on the main instance and on all workers; the Redis address is set with QUEUE_BULL_REDIS_HOST. A worker is started with the command n8n worker, in Docker like this:

docker run --name n8n-worker \
  -e EXECUTIONS_MODE=queue \
  -e QUEUE_BULL_REDIS_HOST=redis \
  -e N8N_ENCRYPTION_KEY=... \
  docker.n8n.io/n8nio/n8n worker

Requirements from the documentation:

• all processes must use the same PostgreSQL database — a distributed setup on SQLite is not supported;
• the encryption key N8N_ENCRYPTION_KEY must be identical on the main instance and all workers, otherwise they will not be able to decrypt credentials;
• binary data cannot be stored on the filesystem of a separate server: this option is not supported in queue mode.

Maintaining a self-hosted installation

Updates. Version 2.0 was released in December 2025. It enables isolated task runners for code nodes by default, code nodes are denied access to environment variables, nodes for executing arbitrary commands are disabled, and changes in a workflow only take effect after explicit publishing. The 1.x branch received only security and bug fixes for three months after 2.0 was released. Before upgrading to a new major version, read the list of breaking changes and test the upgrade on a copy.

Backups. The primary backup is a dump of the PostgreSQL database together with the encryption key. Additionally, workflows and credentials can be exported to files by n8n:

n8n export:workflow --backup --output=backups/workflows/
n8n export:credentials --backup --output=backups/credentials/

Credentials are exported encrypted and can only be restored on an installation with the same key. The --decrypted flag saves them in plaintext — this is used only when migrating to an installation with a different key, and such files must not be left on the server.

Execution history. n8n stores data for each execution in the database and by default deletes records older than 14 days (variable EXECUTIONS_DATA_MAX_AGE, 336 hours) or beyond 10,000 entries (EXECUTIONS_DATA_PRUNE_MAX_COUNT). If workflows process personal data, the retention period for history should be reduced.

How to choose

Common mistakes

• Cloud version for website requests. Customer names and phone numbers go to servers in Germany, which contradicts the personal data localization requirement.
• Checking every minute on a cloud plan. The execution quota is exhausted in the first days of the month.
• Workers with different encryption keys. Executions fail when accessing credentials.
• Upgrading to a new major version without testing. After switching to 2.0, code nodes that read environment variables or executed commands stop working.
• Backups of the database only without the encryption key. Workflows are restored, but all service connections must be recreated.