Best Option to Deploy and Self-Host Your N8n Instance

There is no single “best” place to host n8n. The right answer depends on how much you want to manage yourself, how much memory your workflows need, and what you are willing to pay. This guide gives you a way to decide, the facts I could verify from each provider’s own pages, and the setup mistakes that cause most self-hosting problems.

Updated October 2026: the original version of this post (July 2025) ranked nine providers with detailed price tables. Provider prices and free tiers change constantly, and several figures in it had gone stale: Oracle’s free Arm allowance is now half what the post said, AWS no longer offers the 12-month free micro instance to new accounts, Hostinger’s advertised price was a promotional rate that renews much higher, and the security advice recommended a basic-authentication setting that n8n removed in version 1.0. I rewrote it around decisions rather than a price list, kept only figures I re-checked against official pages in October 2026, and dated them. Anything price-related here will change, so treat the linked pricing pages as the source of truth.

Step Zero: Do You Need to Self-Host at All?

n8n’s documentation frames the first decision as Cloud or self-hosted. Self-hosting gives you control and, with the Community edition, no licence fee. It also makes you responsible for updates, backups, security and uptime. n8n itself says it recommends self-hosting for experienced users, because mistakes can mean data loss, security problems and downtime.

n8n Cloud, per its pricing page, starts at €20 per month (Starter, 2,500 executions) and €50 per month (Pro, 10,000 executions) when billed monthly, and all plans include unlimited users and workflows. If you value your time at more than the difference between that and a small VPS, and your volume fits, Cloud is the simple answer. Self-host when you need control over where data lives, have high execution volumes, or want to learn the platform.

How to Choose a Host: The Criteria That Matter

• Memory first. n8n’s docs don’t publish a minimum for a basic install, but their Hetzner guide says a CPX11 server is enough for a standard deployment and that adding the n8n Assistant needs at least 4 GB of RAM and 2 vCPUs. As a rule of thumb, 1 GB is hobby territory (see my Google Cloud e2-micro guide for its limits), 2 GB suits light production, and 4 GB or more is comfortable.
• Real monthly cost, not the headline price. Include the public IP address, backups or snapshots, bandwidth overage, and the renewal price when a first-term discount ends.
• Your skills. A VPS with Docker Compose needs basic Linux and DNS knowledge. Managed Kubernetes needs a lot more.
• Region and data rules. Where the server is matters for latency and for data-protection requirements.
• Backups and recovery. Decide how you will back up before you need to restore. Provider snapshots help, but they are not a substitute for backing up n8n’s own data.
• The exit plan. Choose a setup you can move. A Docker Compose file and a backup of n8n’s data directory work on any host.

The Main Options, With What I Could Verify

n8n documents deployment guides for DigitalOcean, Hetzner and Heroku (Docker Compose), Google Cloud Run (serverless containers), AWS, Azure and Google Kubernetes Engine (Kubernetes), plus a generic Docker Compose guide for any other Linux server. The table summarises what I could confirm from official pages in October 2026.

Sources: n8n Hetzner guide, Hetzner Cloud, DigitalOcean Droplet pricing, Hostinger n8n hosting, Oracle Always Free resources, Google Cloud Always Free and network pricing, and AWS Free Tier. I am not comparing performance, because I did not benchmark any of them.

My Practical Recommendations

• Learning or a few light workflows: a small VPS with 2 GB of RAM (for example the $12 DigitalOcean Droplet size, or a comparable plan from Hetzner or Hostinger) is a better first server than a 1 GB free tier. Oracle’s free Arm instance can work if you can tolerate account-verification friction and the reclamation rule.
• Business workflows that must stay up: 4 GB or more, PostgreSQL instead of SQLite, tested backups, and monitoring. n8n’s own Docker Compose docs recommend PostgreSQL for production use.
• You mostly want to avoid server work: n8n Cloud.
• You already live in a major cloud: use n8n’s Cloud Run or Kubernetes guides for that provider rather than a VPS, and budget for the extra engineering.

Security Basics (Corrected)

The original security section recommended enabling “N8N_BASIC_AUTH”. That option was removed in n8n 1.0; current versions use built-in user management instead. The essentials today:

1. Create the owner account immediately after first start and use a strong unique password with two-factor authentication.
2. Do not expose n8n’s port directly. Bind it to localhost (127.0.0.1:5678) or use your provider’s firewall, and put a reverse proxy with HTTPS in front. n8n’s reverse-proxy guide says to set the public webhook URL (N8N_WEBHOOK_URL, which replaced WEBHOOK_URL in n8n 2.35.0) and N8N_PROXY_HOPS=1.
3. Open only what you need in the firewall: 80 and 443, with SSH limited to your own address where possible.
4. Protect the encryption key. n8n encrypts stored credentials with a key kept in its .n8n folder (or N8N_ENCRYPTION_KEY). Without it a restored database can’t be decrypted.
5. Pin versions and update regularly. n8n’s update guidance is to update at least monthly after reading the release notes. Don’t run latest unattended.
6. Treat webhooks as public endpoints. Validate their input and use authentication on them where possible. See n8n’s security documentation.

Backups

n8n’s backup documentation says a complete backup includes the .n8n folder (which holds the encryption key and, with the default SQLite database, the database itself) plus your external database if you use PostgreSQL. With SQLite, stop n8n before copying, since copying a database file while it is being written can give an inconsistent backup. CLI exports of workflows and credentials are useful for moving between servers but do not include users, execution history or the encryption key. Store backups off the server, and test a restore at least once. For the exact commands on Docker Compose, see the step-by-step Google Cloud guide, which applies to any Debian server.

When You Outgrow One Server

n8n’s queue mode splits the work: a main instance handles triggers and webhooks and places executions on a Redis queue, and worker instances pick them up and run them, so you can add workers as load grows. It needs PostgreSQL (n8n says running queue mode with SQLite isn’t recommended), the same encryption key on every instance, and S3-style external storage if workflows must keep binary data, because queue mode doesn’t support filesystem binary storage. That is a bigger operational commitment, so move there only when one well-sized server is no longer enough.