How to Host n8n Workflows on Your Own Server

n8n hosting on a server you control is possible, but “self-hosted” does not automatically mean “maintenance-free.” You gain control over infrastructure, custom nodes, execution data, and operating limits. You also inherit responsibility for updates, backups, HTTPS, database health, queue workers, and recovery.

The right n8n hosting route depends on which part you actually want to own. A managed server can preserve the flexibility of self-hosting while a provider handles the operating system. A raw VPS costs less but makes you the administrator. n8n Cloud removes almost all infrastructure work, though it is not self-hosting.

This guide compares the practical routes, explains a production-ready architecture, and gives you a deployment checklist. Prices and product details were checked against first-party pages in September 2026.

TL;DR: choose n8n hosting by what you want to manage

Route	Best for	Price checked September 2026	Your responsibility
xCloud managed n8n hosting	Teams that want self-hosted n8n without server administration	Managed 8 GB server from $45/month; BYOS panel free for one server	n8n workflows, credentials, and integrations
n8n Cloud	Teams that do not need infrastructure control	Starter €20/month billed annually	Workflows and credentials
Hetzner or DigitalOcean VPS	Linux users who want full control and a low base cost	Hetzner from €5.99/month; DigitalOcean from $4/month	The complete server, n8n, database, security, and backups
Railway or another app platform	Developers who prefer services and containers to VM administration	Usage-based	Packaging, persistence, database, and spend controls
Docker on existing infrastructure	Teams with established container operations	Existing capacity plus operations	Everything from the container runtime upward

If you only remember one line: use xCloud when you want self-hosted n8n with managed operations, use n8n Cloud when you do not need to own the host, and use a VPS only when maintaining Linux is part of your plan.

What self-hosted n8n needs

Self-hosted n8n needs persistent storage, a stable database, HTTPS, a public webhook URL, and a process that survives restarts. A container that starts successfully is only the first step. Production readiness depends on what happens after an update, a disk fills, or the host reboots.

The official n8n hosting documentation supports self-hosting on your own infrastructure, on-premises hardware, or a private cloud. It documents Docker-based setup, cloud-provider routes, and npm installation. The free Community edition runs without a license key; paid self-hosted editions add commercial features.

A basic deployment has these components:

1. n8n application: the editor, API, webhooks, and execution engine.

2. Database: SQLite can work for evaluation, while PostgreSQL is the usual production choice.

3. Persistent storage: configuration and any files that must survive container replacement.

4. Reverse proxy and TLS: a stable HTTPS endpoint for the editor and webhooks.

5. Backups: copies of the database, encryption key, and essential configuration.

6. Monitoring: checks for process health, failed executions, disk usage, and certificate renewal.

Here is the part that trips people up: workflow credentials are encrypted with an n8n encryption key. Backing up the database without preserving that key can leave restored credentials unusable. Treat the key as both a secret and a recovery dependency.

The xCloud One Click Apps catalogue is the hub for deploying n8n and other self-hosted applications without assembling each stack by hand.

The five practical hosting routes

There is no single best host for every n8n workload because the products move the operational boundary to different places. Compare who handles the operating system, database, backups, and recovery rather than comparing CPU and memory alone.

Responsibility	xCloud managed	n8n Cloud	Raw VPS	App platform	Existing Docker stack
Provision host	Provider	Provider	You	Provider	You
Install n8n	Provider workflow	Provider	You	You	You
Patch operating system	Provider	Provider	You	Provider	You
Back up application data	Included server backups; verify scope	Provider-managed service	You	You	You
Configure HTTPS	Provider workflow	Provider	You	Platform plus your config	You
Restore after failure	Provider-assisted	Provider	You	Shared responsibility	You
Add custom nodes	Supported within product constraints	Plan-dependent	Full control	Usually possible	Full control

The cheapest monthly line item is not always the cheapest route. Operations consume time, and an automation service often becomes infrastructure for other business systems. Downtime can block every workflow that depends on it.

1. xCloud managed n8n hosting

xCloud is the strongest option for teams that want n8n on their own server without taking on routine server administration. The service deploys n8n from the dashboard and handles the operating system, security patching, daily backups, SSL, monitoring, and support.

The live xCloud n8n hosting page recommends at least 4 GB RAM and two CPU cores. Its managed pricing section showed 8 GB server options from $45 per month when checked in September 2026. That price includes the server and management rather than requiring a separate infrastructure invoice.

xCloud also supports a bring-your-own-server route. The page lists one server and up to ten sites free, then panel pricing per server as the fleet grows. You still pay the cloud provider directly and remain responsible for whatever falls outside the panel’s management boundary.

✅ Pros	❌ Cons
✅ One-click n8n deployment with no terminal required	❌ Higher monthly price than the smallest unmanaged VPS
✅ SSL, daily backups, monitoring, and OS patching are included	❌ Low-level system customization is less direct than administering a raw VM
✅ Unlimited workflows are not priced per task by the hosting layer	❌ n8n licensing and external API costs remain separate
✅ Managed and bring-your-own-server routes use the same control panel	❌ You still own workflow logic, credentials, and integration failures

Choose xCloud when n8n is part of your operations but Linux maintenance is not. It also fits agencies that want to deploy several open-source tools from one panel rather than maintain unrelated installation scripts.

2. n8n Cloud

n8n Cloud is the simplest route when you do not need to own the infrastructure. n8n operates the service, and pricing is based on workflow executions rather than each step in a workflow.

The n8n pricing page showed Starter at €20 per month billed annually and Pro at €50 per month billed annually when checked in September 2026. The page states that plans include unlimited users, workflows, and integrations, while execution allowances and feature limits vary.

n8n Cloud is a useful baseline for comparison because it removes almost every hosting task. The trade-off is less infrastructure control and a cost model tied to execution volume. Self-hosting can be more economical at high volume, but only if the server and operational work are managed well.

✅ Pros	❌ Cons
✅ No server provisioning, patching, or backup system to build	❌ It is not self-hosted infrastructure
✅ Official service with straightforward onboarding	❌ Pricing scales with workflow executions and plan limits
✅ Support and product operations come from the n8n team	❌ Some self-hosted capabilities and system-level customization are unavailable

Choose n8n Cloud when your main goal is workflow automation and the official plan limits fit the workload. Do not self-host merely to avoid a subscription if nobody on the team can own recovery.

3. A self-managed VPS

A raw VPS is the lowest-cost route for technically capable operators who want full control. Providers such as Hetzner and DigitalOcean supply the virtual machine; you install Docker, PostgreSQL, n8n, a reverse proxy, monitoring, and backups.

Hetzner’s regional cloud page listed cost-optimized plans from €5.99 per month, while DigitalOcean’s Basic Droplets started at $4 per month when checked in September 2026. Those are infrastructure entry prices, not complete production costs. Backups, storage, managed databases, monitoring, and administrator time can add to the total.

A small VM may handle light personal workflows, but xCloud’s n8n page recommends 4 GB RAM and two CPU cores for its deployment flow. Treat that as a more practical baseline when workflows run concurrently, process larger payloads, or use AI nodes.

✅ Pros	❌ Cons
✅ Lowest raw infrastructure cost and full root access	❌ You own hardening, updates, backups, and incident response
✅ Freedom to add custom nodes and system packages	❌ A failed update can stop every workflow until you recover it
✅ Easy to move between providers when the deployment is portable	❌ The database and encryption key need a tested recovery plan

Choose a VPS when Linux administration is already a team capability. The best Docker hosting providers guide compares infrastructure options if containers are your preferred deployment unit.

4. An application platform

An application platform is a middle ground for developers who want managed infrastructure but still package n8n as a service. Platforms such as Railway handle much of the host lifecycle and offer logs, environment variables, networking, and usage-based billing.

The platform does not remove n8n’s stateful requirements. You still need persistent storage, a database, the encryption key, a stable URL, and a clear process for upgrades. You should also set spend controls because execution spikes can increase usage-based charges.

✅ Pros	❌ Cons
✅ Less operating-system work than a raw VPS	❌ Stateful storage and database design remain your responsibility
✅ Convenient deployment, logs, and environment controls	❌ Usage billing can be less predictable than a fixed server
✅ Good fit for teams already using containers and managed services	❌ Platform constraints can complicate custom binaries or long-running jobs

Choose an app platform when the team already treats applications as reproducible services. A fixed VPS is often easier when n8n needs many system tools or the host doubles as an interactive administration environment.

5. Docker on infrastructure you already operate

Running n8n on an existing Docker or Kubernetes environment is efficient only when that environment already has production operations. Reusing spare compute is not a saving if you still need to invent backups, TLS, secrets management, and monitoring.

The official n8n documentation supports Docker-based methods, and containers make upgrades and rollback more repeatable. However, a container image does not back up PostgreSQL, preserve the encryption key, or guarantee webhook availability. Those remain platform concerns.

✅ Pros	❌ Cons
✅ Reuses established networking, monitoring, and backup tooling	❌ Complexity is excessive for a team without existing container operations
✅ Reproducible deployments and straightforward image rollback	❌ Shared clusters can create noisy-neighbor and dependency risks
✅ Fits infrastructure-as-code and Git-based change control	❌ Database and persistent-volume recovery still need separate testing

Choose this route when your organization already operates containers reliably. If you are building the platform only to run one n8n instance, a managed server or simple VPS will usually be easier.

A production-ready n8n architecture

A production n8n deployment separates public ingress, application processing, persistent data, and backup storage. On one server, those layers can still be distinct services so each can be upgraded and restored deliberately.

A practical single-host architecture looks like this:

1. DNS points a dedicated subdomain to the host.

2. A reverse proxy terminates HTTPS and forwards requests to n8n.

3. n8n runs as a supervised container or service.

4. PostgreSQL stores workflows, credentials, and execution metadata.

5. Persistent volumes hold required application data.

6. Backups leave the server and follow a retention policy.

7. Monitoring checks the editor, webhook endpoint, queue depth, disk, and database.

For higher workload or availability needs, n8n can use queue mode with separate main, worker, and webhook processes. Redis coordinates queued work, while PostgreSQL remains the system of record. Scale only after measurement shows a bottleneck; a distributed stack creates more failure modes than a single healthy server.

Step-by-step deployment checklist

A reliable n8n deployment starts with recovery requirements, not the install command. Work through these steps before sending production webhooks to the instance.

1. Choose the operating boundary

Decide whether the provider manages the operating system, n8n itself, or neither. Write down who patches Linux, renews certificates, monitors disk usage, and responds to failed backups.

2. Size the first server

Start with at least 4 GB RAM and two CPU cores for a practical general-purpose deployment, then measure. Workflows that process large files, run code, call AI models, or execute concurrently may require more memory.

3. Create a stable domain and HTTPS endpoint

Use a dedicated subdomain. Configure TLS before registering production webhooks, because changing the base URL later can disrupt callbacks and OAuth integrations.

4. Use PostgreSQL for production

Provision PostgreSQL with its own persistent storage and credentials. Restrict network access so the database is not publicly reachable.

5. Preserve the encryption key

Generate and store the n8n encryption key in a secrets manager or another protected location. The backup plan must include both the database and this key.

6. Configure execution retention

Set a retention policy for successful and failed executions. Unlimited execution history can fill the database and disk, causing failures unrelated to workflow logic.

7. Back up off-host

Back up PostgreSQL, the encryption key, and essential configuration to storage outside the server. Encrypt the backup and define retention.

8. Test restore and update procedures

Restore into a separate environment and confirm that workflows and credentials function. Then document how to update n8n, verify it, and roll back when a release causes a problem.

9. Add monitoring and alerts

Monitor HTTP health, failed executions, queue depth where applicable, database availability, memory, disk, and certificate expiry. Route alerts somewhere the team actually watches.

10. Restrict administrative access

Protect the editor with strong authentication, minimize exposed ports, and restrict SSH. Review credentials and integration permissions regularly.

How much n8n hosting really costs

The real monthly cost is infrastructure plus operations plus the services each workflow calls. n8n may be free to self-host in the Community edition, but the host, database, backups, observability, email delivery, and external APIs are not automatically free.

Use this budget model:

Monthly cost = server + database + storage/backups + monitoring + external API usage + administrator time

For a single instance, a VPS can minimize the first four cash expenses when you operate everything yourself. Managed n8n hosting costs more but converts some administrator time and recovery risk into a predictable bill. n8n Cloud replaces infrastructure cost with an execution-based subscription.

If n8n is part of a broader self-hosted stack, consolidate operations carefully. xCloud can deploy from its One Click Apps catalogue, while the OpenPanel versus PostHog comparison and OpenPanel guide cover analytics tools that may sit beside automation. The open-source website builders round-up covers another common workload. Shared hosting can reduce overhead, but one overloaded server can also become a shared point of failure.

When to scale beyond one instance

Scale n8n when measurements show queueing, memory pressure, slow webhooks, or unacceptable recovery time. Do not distribute a healthy low-volume instance merely because horizontal scaling exists.

Signals that justify a larger or multi-process architecture include:

• concurrent executions regularly consume all available workers;
• webhook response latency exceeds the application’s tolerance;
• memory pressure causes restarts or failed jobs;
• one workflow blocks unrelated work;
• maintenance windows are no longer acceptable;
• restore time exceeds the business recovery objective.

The first step is often a larger server and cleaner execution retention. Queue mode becomes useful when you need independent workers, controlled concurrency, or horizontal processing. At that point, PostgreSQL and Redis must be treated as critical services with their own monitoring and backup plans.

Frequently asked questions

Can I host n8n for free?

The n8n Community edition is available for self-hosting without a license key, but infrastructure still has a cost unless you use existing or free-tier capacity. xCloud’s bring-your-own-server panel lists one server and up to ten sites free, while you continue paying the infrastructure provider. External APIs used by workflows may also charge separately.

How much RAM does n8n need?

Memory depends on workflow size, concurrency, payloads, code execution, and connected nodes. A small test instance can run with limited resources, but xCloud recommends at least 4 GB RAM and two CPU cores for its n8n deployment. Monitor actual memory use before increasing capacity.

Is self-hosted n8n cheaper than n8n Cloud?

Self-hosting can have a lower infrastructure bill, especially at high execution volume, but it transfers updates, backups, security, and recovery to you. n8n Cloud can be cheaper in total when the team lacks server-operations capacity. Compare the full operating cost, not only the VPS price.

Should I use SQLite or PostgreSQL for n8n?

SQLite is convenient for evaluation and small local setups. PostgreSQL is the safer production choice because it supports stronger operational practices and future scaling. Whichever database you choose, back it up with the n8n encryption key and test a restore.

Does n8n hosting include the APIs my workflows call?

No. Hosting runs n8n, but services such as AI models, email providers, databases, and third-party APIs have separate credentials, limits, and bills. Include those costs in the workflow budget and set provider-level alerts where available.

Can I host other applications on the same server?

Yes, if the server has enough capacity and the workloads are isolated. The trade-off is a larger blast radius: an overloaded disk, failed update, or security incident can affect every application. Monitor per-service usage and keep independent backups.

Verdict

xCloud is the best default when you want self-hosted n8n without managing the server, while a raw VPS is best for operators who explicitly want full control. n8n Cloud wins when infrastructure ownership offers no business value. Application platforms fit teams that already deploy stateful services that way.

The honest comparison is not managed versus cheap. It is managed responsibility versus self-managed responsibility. If n8n becomes the connective tissue between sales, support, finance, and engineering, recovery matters more than saving a few dollars on the smallest VM.

Choose the operating model before the server

List the workflows that must stay online, define how quickly they need to recover, and assign a named owner for updates and backups. Then choose the hosting route that meets those requirements.

If you want the flexibility of self-hosted n8n without routine Linux work, review xCloud n8n hosting and verify the current managed or bring-your-own-server plan. If you choose a VPS, complete a restore test before connecting production credentials.

Pick the operating boundary your team can sustain, deploy one representative workflow, and prove the backup before moving the rest.

Want practical hosting guides without the hype? Subscribe to the xCloud newsletter and join the xCloud community for deployment notes, comparisons, and real-world server advice.