n8n hosting on a CPU VM: sizing, backups, and costs

Hosting n8n on a CPU VM makes sense when you need control over the runtime, network access, and data storage, and someone can operate the service. Choose capacity from the workflows you expect to run together. The number of workflows saved in the editor tells you little about peak memory, execution time, or recovery needs.

This guide helps you choose between managed n8n and self-hosting, estimate the VM portion of the budget, and plan persistence, backups, and growth. The documentation and calculations were checked on November 11, 2026. No n8n deployment, workload benchmark, or restore was run for this article; the sizing process below requires measurements from your workflows.

Choose the operating model before the VM

Use n8n Cloud when you want n8n to operate the hosting environment and its available plans meet your requirements. Choose a self-managed VM when control over dependencies, private connectivity, or deployment configuration is worth the maintenance work.

A CPU instance from Compute with Hivenet supplies infrastructure. It does not make Hivenet the operator of your n8n application, database, backups, or workflows. Assign a person to upgrades, monitoring, credentials, and recovery before moving a business-critical automation onto it.

Check the selected n8n edition early. The official edition comparison distinguishes free Community options from paid self-hosted plans. Features such as sharing, external secrets, and external binary storage can affect the choice. Self-hosting does not automatically include every paid feature; check current pricing and license terms for your intended use.

Match CPU and memory to the workflow

Consider three different jobs. A scheduled CRM synchronization may spend much of its time waiting for API responses. A reporting workflow that loads large JSON datasets may need substantial memory. An AI workflow that calls a remote model needs capacity to coordinate requests, while model inference runs elsewhere. Those jobs should not receive the same sizing estimate merely because each is one workflow.

For the first capacity test, record:

• The busiest arrival period, including overlapping schedules and webhook bursts.
• Typical and maximum input sizes, especially files and large JSON arrays.
• Concurrent executions, completion time, and the acceptable waiting time.
• Peak memory, sustained CPU use, database activity, and disk growth.
• External API limits, retry behavior, and the effect of a slow dependency.

Start with a small representative workload, then increase concurrency while watching memory and completion time. Include the operating system, database, reverse proxy, and any task runners in the memory budget if they share the VM. Do not allocate all RAM to a single process.

n8n's memory guidance identifies large payloads, some code-heavy nodes, manual execution copies, and simultaneous workflows as contributors to memory pressure. Processing smaller batches can be more useful than buying CPU for a workload constrained by memory or an external API.

Choose a deployment you can maintain

Use the current n8n Docker Compose guide as a starting point, then identify which services you actually need. Its current example includes the AI Assistant sandbox stack and states a minimum of 2 vCPU and 4 GB RAM for that setup. That is not a benchmark showing that every production n8n workload fits in 4 GB.

Separate workflow execution requirements from optional AI services. Review any privileged sandbox component before including it in a production design. Pin the versions you deploy and keep the configuration reproducible, with secrets stored outside the repository.

n8n supports SQLite and PostgreSQL. SQLite can keep a small installation simple; PostgreSQL adds a separate database to operate or purchase. Check n8n's current database support policy when choosing a version. Our PostgreSQL hosting guide explains the tradeoff between a managed database and one you operate yourself.

Putting n8n and PostgreSQL on one VM reduces the number of machines, but they share capacity and a failure boundary. Moving the database elsewhere changes the cost and network requirements; it does not remove the need for backups and restore checks.

Plan persistent data and a usable backup

Map the data locations before launching: the n8n user folder, the database, binary files, custom-node directories, and deployment configuration. Persisting a container's data across recreation is useful, but it is not a separate recovery copy if the VM or disk is lost.

Keep the credential encryption key recoverable and access-controlled. n8n's encryption-key documentation explains how the generated or configured key protects credentials. A restored database containing encrypted credentials still needs the matching key. Do not put the key value in a public repository or planning worksheet.

Follow the full-instance backup guidance. Workflow and credential exports alone do not contain every part of an instance. Include the relevant user folder, external database, custom paths, and external storage. For SQLite, stop writes before an ordinary file copy or use a method that produces a consistent database backup.

Choose recovery targets in practical terms: how much recent work can be lost, and how long can the automation be unavailable? Test restoration in an isolated environment that cannot send real notifications, update customer records, or trigger payments. Verify that credentials decrypt and a harmless test workflow completes before calling the backup usable.

Execution history also consumes storage. Decide what to retain for debugging and evidence, then configure pruning using n8n's execution-data guidance. Watch actual disk use afterward; deleting records does not necessarily shrink database files immediately.

Make webhooks and monitoring part of the design

A workflow that runs in the editor is not proof that an external webhook reaches it correctly. Check DNS, HTTPS, the public webhook URL, and the reverse-proxy path. The current proxy documentation uses N8N_WEBHOOK_URL; older examples may use a deprecated name. Match trusted proxy settings to the actual request path rather than copying them blindly.

Monitor workflow failures and duration alongside CPU, memory, disk, and database health. n8n distinguishes a reachable process at /healthz from database readiness at /healthz/readiness. Neither proves that an external API or a particular workflow is working. Its monitoring reference explains these endpoints and how metrics are enabled.

Use a harmless scheduled check for the business path that matters, such as reading a test record and writing a result to a dedicated test destination. Set notifications that someone owns. A failed automation that nobody notices is still failed.

Estimate the VM cost separately from operations

The Hivenet CPU instance page lists €0.0175 per vCPU-hour, with 2 GB RAM per vCPU and 50 GB NVMe included, as checked on November 11, 2026. These examples multiply that rate by 730 hours. They are VM-only illustrations, not n8n capacity recommendations or full hosting quotes.

Actual use is billed by the second, and calendar months vary in length. Confirm current terms, tax treatment, and any additional charges before purchasing. The included disk is shared by whatever you store on that VM, including database growth and logs.

Add database or queue services, backup storage, monitoring, paid n8n features, external APIs, and operator time to the budget. For example, €51.10 for the VM plus assumed monthly costs of €8 for backups, €20 for APIs, and two operator hours at €60 gives €199.10. Only the VM rate comes from the cited product page; all other amounts are hypothetical, and omitted costs still need adding. The point is to expose the costs, not to claim a universal saving over n8n Cloud.

Add queue mode when the evidence justifies it

If executions accumulate despite an appropriate single-instance configuration, review n8n queue mode. It separates the main process from execution workers and uses Redis to coordinate work. Workers need compatible database access and the same credential encryption key. Queue mode adds components to monitor, update, and recover.

Check binary-data handling before moving file-heavy workflows. Queue mode does not support persisted binary data on the local filesystem, and external storage availability depends on the n8n edition. The external-storage documentation also distinguishes official support from S3-compatible services that need separate validation. Do not assume that an arbitrary bucket or local mount completes this design.

More workers on the same VM share its CPU and RAM. They do not create more hardware or make that VM highly available. First identify whether the bottleneck is execution concurrency, memory, database work, or a downstream service.

Decide using an acceptance test

Before relying on the service, verify the representative peak workload, external webhook delivery, restart persistence, an isolated restore, and the response to API errors. Keep a record of the chosen n8n version, enabled features, VM size, retention policy, and who handles incidents.

Use n8n's update guidance to plan changes. Take a complete backup, test the target version, and account for database migrations; switching an image tag back does not necessarily undo them. A CPU VM is a good fit when the measured workload and operating responsibilities are manageable. If those responsibilities have no owner, choose managed hosting before optimizing a small difference in server price.