Self-hosting n8n: setup, monthly cost and what you take on

To self-host n8n, you run its free Community edition in Docker on a server you rent, with PostgreSQL for the data and a reverse proxy for HTTPS. The server is the cheap part. A Hetzner CX23 with 2 vCPUs and 4 GB of memory costs €5.99 a month in Germany or Finland before VAT (Hetzner, checked 1 November 2026). The hours cost more, and n8n's own hosting guides recommend self-hosting "for expert users". Below: the setup, server sizing, a security checklist, the monthly cost with upkeep hours, and the point where n8n Cloud is cheaper.

Two things to know first. n8n automation is one of the services we sell, so every price here comes from the provider's own page with the date we checked it, and there are no affiliate links. And the upkeep hours are planning estimates. We have no log from a production n8n server to publish, so each hour is shown on its own line for you to replace with yours.

What does self-hosting n8n involve?

Self-hosted n8n is n8n running on infrastructure you control. Without a licence key it runs as the Community edition (n8n docs), which is free when only people in your organization create or edit the workflows (n8n licence FAQ). Our plain-English reading of the n8n licence covers the edge cases, such as agencies and products that embed n8n. This paragraph and that post are our reading of n8n's FAQ, not legal advice.

A production setup has four parts:

1. n8n itself, from its Docker image. Plan on Docker even if you've seen npm guides: "n8n 3.0 no longer supports installations run using npm or npx n8n" (n8n 3.0 breaking changes).
2. PostgreSQL for the data. n8n uses SQLite unless told otherwise. Its Compose guide says "SQLite is fine for trying things out" and recommends Postgres for an instance that "must handle more than a handful of users or workflows running around the clock" (n8n docs).
3. A reverse proxy for HTTPS. n8n's DigitalOcean and Hetzner guides use Caddy, which "automatically creates and manages SSL/TLS certificates" (n8n docs).
4. The upkeep: updates, backups, monitoring and access. n8n's own comparison puts self-hosted maintenance down as "Your responsibility" (n8n docs).

You also give up some features. The Community edition has no SSO, projects, Git-based environments or sharing, and "only the instance owner and the user who creates them can access workflows and credentials" (n8n docs). Those come with the self-hosted Business plan at €667 a month billed annually (n8n pricing, checked 1 November 2026).

What size server does n8n need?

For a small business that doesn't use n8n Assistant, 2 vCPUs and 4 GB of memory is a comfortable start, and 2 GB is enough for light use. n8n's sizing example, based on n8n Cloud and labelled "for illustrative purposes only", lists 320 MB to 2 GB of memory and 512 MB to 4 GB of SSD for the database. It also says "n8n isn't CPU intensive", and an idle n8n Cloud instance needs about 100 MB (n8n docs).

Memory is what runs out. The same page explains why: the Code node "creates a pre-processing and post-processing copy of the data", and with large binary files "this can consume all available resources". Postgres and Caddy need memory too, so we'd go to 4 GB as soon as PDFs, images or Code nodes are part of the work.

Our sizing rule of thumb, built on n8n's figures:

n8n Assistant changes the numbers. Its sandbox "uses Docker-in-Docker, which needs more headroom than a typical container", so the Compose guide asks for at least 4 GB and 2 vCPUs. Its default stack includes that sandbox, so following it as written needs the 4 GB. For production, n8n "currently recommends Daytona as the sandbox provider instead" of the bundled one.

Queue mode is how n8n grows past one server: the main instance receives triggers, Redis queues the executions and workers run them (n8n docs). The Community edition includes it. We wouldn't start with it.

What does a self-hosted n8n server cost per month?

About $8 to $31 a month for the server and its backups on the four setups below. Prices were checked on 1 November 2026, and Hetzner's include an IPv4 address and exclude VAT (cost-optimized, regular performance, DigitalOcean).

How the rows are worked out:

• Hetzner bills backups as "a monthly flat price, which is 20% of the price of the server" (Hetzner FAQ) and takes them daily into 7 slots (Hetzner docs). DigitalOcean charges 20% of the droplet price for weekly backups or 30% for daily ones.
• Provider backups don't replace your own. Hetzner's backups "are bound to a single server and will automatically be deleted if you delete the server" (Hetzner FAQ), so also copy a nightly database dump and the n8n data folder somewhere else, and add that storage to the bill.
• Euros are converted at the European Central Bank's reference rate for 30 October 2026, €1 = $1.1172 (ECB).
• Prices move. Hetzner's adjustment of 15 June 2026 took the CX23 from €3.99 to €5.49 a month and the US CPX11 from €5.99 to €17.49, both before the IPv4 address, for new orders and resizes (Hetzner). The CPX11 is the plan n8n's Hetzner guide still calls "enough" for "most usage levels" (n8n docs).
• Hetzner says of its cost-optimized line that "the number of available servers is limited", so the CX23 may not always be there to order.

Not in the table: the domain, an SMTP service for user invites and password resets if you don't already have one, and the hours, which come next.

How do you set up n8n with Docker Compose?

Here is the order we'd follow. n8n's n8n-docker-caddy repository, which its DigitalOcean and Hetzner guides use, gives you n8n and Caddy. You add Postgres from the Compose guide.

1. Rent the server in your company's name, in the region where your data should live, and log in with an SSH key. n8n's Hetzner guide puts it simply: "SSH is more secure."
2. Point a subdomain such as n8n.example.com at the server with a DNS A record.
3. Allow only ports 80 and 443, plus SSH, in your provider's cloud firewall. The next section explains why a firewall on the server itself isn't enough.
4. Install Docker with the Compose v2 plugin.
5. Write compose.yml with three services: n8n, Postgres and Caddy. Pin n8n's image to a version; n8n's Compose guide reads it from N8N_VERSION in .env. On 1 November 2026 n8n's hosting guides listed 2.45.7 as the current stable release. For Postgres, use postgres:18 and keep the PGDATA line, because without it "your database starts empty".
6. Set your own encryption key before the first start and save a copy in your password manager. Otherwise n8n "creates a random encryption key automatically on the first launch" and saves it in its data folder (n8n docs).
7. Set the public webhook address and proxy setting, so services that call your webhooks get the right URL (n8n docs).
8. Start it with docker compose up -d, open your address, create the owner account and turn on 2FA under Settings, Personal (n8n docs).
9. Point an uptime monitor at /healthz/readiness, which returns 200 only "if the DB is connected and migrated". Plain /healthz doesn't check the database (n8n docs).
10. Run the security audit, take a first backup and restore it on a spare server before you build anything that matters.

These are the n8n settings that matter most for steps 5 to 7, with placeholder values. They come from n8n's docs linked above; put them wherever your Compose setup passes environment variables to n8n:

N8N_ENCRYPTION_KEY=<long random string, copied to your password manager>
N8N_WEBHOOK_URL=https://n8n.example.com/
N8N_PROXY_HOPS=1
DB_TYPE=postgresdb
DB_POSTGRESDB_HOST=postgres
DB_POSTGRESDB_DATABASE=n8n
DB_POSTGRESDB_USER=<database user>
DB_POSTGRESDB_PASSWORD=<database password>

What do n8n's example files leave out?

We read the files in n8n-docker-caddy on 1 November 2026. They work as a start, with three gaps to close before production:

• n8n's own port is open to the internet. The compose file publishes 5678:5678, so n8n also answers on plain HTTP at the server's address. The guides open 80 and 443 with ufw, but Docker's published ports skip ufw: "Packets are routed before the firewall rules can be applied, effectively ignoring your firewall configuration" (Docker docs). Docker's own warning is that "publishing container ports is insecure by default" (Docker docs). Delete n8n's ports lines, since Caddy reaches n8n inside the Compose network, or bind them to 127.0.0.1:5678:5678. Then block everything else in the provider's firewall too.
• No versions are pinned. It runs docker.n8n.io/n8nio/n8n and caddy:latest, so a routine docker compose pull can jump to a new major version, breaking changes and all, as soon as it becomes the stable release.
• It uses SQLite and an old setting name. There's no database service, and it sets WEBHOOK_URL, which n8n deprecated in 2.35.0 in favour of N8N_WEBHOOK_URL.

What do you take on each month?

About 3 hours a month in our planning, which includes a share of the half day each major version needs. These are estimates for one small instance, so swap in your own:

At $40 an hour, that's $120 a month. We use $40 because it sits near the top of the senior Asia band ($31 to $41 an hour) in Accelerance's rate survey of 60 development partners, published 24 November 2025. An in-house hour in New York or London costs more.

These hours cover the server only. Building and fixing workflows takes the same time on Cloud, so it stays out of this comparison. Our n8n, Zapier and Make cost comparison prices that part.

Two details shape the backup line. A complete backup is the .n8n folder plus the Postgres database, because the folder holds the key: without it "a restored database or encrypted credential export can't be decrypted". And n8n's CLI export alone isn't enough to rebuild an instance, because it leaves out users, execution history, variables and instance settings, the key included.

The major version row applies now, because 3.0 is already out. On 1 November 2026, n8n's docs still marked it as an early access release. Among its changes: no npm installs, encryption key rotation on by default, ~/.n8n/binaryData renamed to ~/.n8n/storage, and a default Code node task timeout cut from 5 minutes to 1 (n8n 3.0 breaking changes). n8n's migration report (Settings, then Migration Report) lists what needs fixing on your own instance before you move.

What running our own servers taught us

We run the Python backends behind our own apps on Linux cloud servers. They aren't n8n, but four lessons from them carry straight over:

• Servers drift from the repository. Given time, what runs on the server stops matching what the repository says. Keep compose.yml and a .env template without secrets in version control, and compare them with the server before every change.
• A deploy must never overwrite the server's .env. That file holds the secrets. With n8n it can hold the encryption key and the database password, and if the key is lost n8n can't decrypt your saved credentials.
• Check what's actually live. Our backends answer a ping with the version they're running, because "I updated it" is worth checking. With n8n, pin the version and confirm it after each update with docker compose images, which lists the image and tag each container uses.
• Files pile up, and restarts drop work in flight. Our media backends needed a cleanup job for generated files older than 24 hours, and a job list held in memory loses its jobs on a restart. n8n prunes execution data by default after 14 days or 10,000 executions, but on SQLite "the disk space of any pruned data isn't automatically freed up" (n8n docs). And runs missed while the instance is down or restarting "aren't recoverable" (n8n docs). Update in a quiet hour and read the failed list afterwards.

Is self-hosted n8n secure?

It's as secure as the server you keep. n8n encrypts saved credentials and supports 2FA, but what faces the internet, how fast you patch and what workflows may run on the host are up to you. Our n8n security checklist:

• Nothing but 80, 443 and SSH reachable from the internet, checked from outside the server. Postgres and port 5678 stay closed.
• 2FA on every account, and SMTP set up for invites. Without SMTP, n8n's docs say "users can't reset passwords" (n8n docs).
• Run n8n audit after setup and once a month. Its nodes report lists built-in nodes you can use "to fetch and run any code on the host system" (n8n docs). Block the ones your workflows don't need.
• Disable the public API if nothing uses it, and turn on SSRF protection, which controls "which hosts and IP ranges workflow nodes can connect to" (n8n security docs).
• Keep updating. Releases carry security changes: 3.0, for example, added webhook signature checks to the Workable Trigger node and a larger default SSRF block list.
• If you run n8n Assistant with the bundled sandbox, n8n says to treat its privileged runner "as equivalent to root on the host" and never expose it.

When is n8n Cloud cheaper than self-hosting?

Whenever the Cloud plan your volume needs costs less than the server plus your upkeep hours. At $40 an hour and 3 hours a month, Cloud is cheaper up to 10,000 executions a month, and the two are about even at 50,000.

n8n Cloud prices by executions, and "an execution is a single run of your entire workflow" (n8n pricing, checked 1 November 2026). Pro comes in two sizes there: 10,000 executions for €600 a year (€60 billed monthly) and 50,000 for €1,450 a year (€145 billed monthly). Here are the plans against the cheapest server above (the Hetzner CX23 with backups, $8.03) plus 3 hours at $40:

Three things move the answer:

• Your hours. The 50,000 row favours self-hosting only while upkeep stays under about 3.2 hours a month ($135.00 minus $8.03, divided by $40). Beating Pro at 10,000 executions would need under 1.2 hours. At $80 an hour, self-hosting costs $248.03 a month and loses to every Pro tier.
• Setup. We'd plan at least a working day for the setup above, restore test included: 8 hours, or $320 at $40. Spread over the first year that's $26.67 a month, which tips the 50,000 row back to Cloud in year one.
• The server. On the 4 GiB DigitalOcean droplet with daily backups, self-hosting costs $31.20 + $120 = $151.20 a month, more than the 50,000 tier.

Some reasons to self-host don't show up in a price table:

• You choose where the data sits. n8n's pricing page says hosted plans keep data "within the EU, on servers located in Frankfurt, Germany". Self-hosted, "it's wherever you decide to host n8n".
• Your server sets the run limits. Cloud Starter allows 5 runs at once and 5 minutes per run. Pro allows 20 or 50 at once, depending on tier, and 40 minutes.
• You keep as much history as your disk holds. Cloud keeps up to 2,500 saved executions on Starter and 25,000 on Pro, with 7 and 30 days of logs.
• A server inside your own network can reach a database or file share you'd never open to the internet.

When not to self-host n8n

• Nobody is named to do the monthly update and the backup checks. An instance nobody updates still needs the 3.0 upgrade later, with more versions to jump at once.
• You need SSO, shared workflows or Git-based environments and won't pay for the Business plan.
• The only reason is saving money below 10,000 executions a month. On the numbers above, it doesn't.
• Your workflows touch payments or personal data and you can't apply a security update within a few days of release.

What we would do

Here is how we would approach it for a business starting out with n8n:

1. Start on n8n Cloud unless a self-hosting reason applies. Workflows export as JSON files (n8n docs), so you can move to your own server later.
2. Self-host when data location, run limits or network reach decide it, or above about 50,000 executions a month with upkeep you can keep under 3 hours.
3. If you self-host, follow the ten steps above on a 2 vCPU, 4 GB server in your company's name, close port 5678, and put a monthly update slot in someone's calendar before go-live.
4. Stay on the 2.x stable line until 3.0 leaves early access, and read the migration report before you move.

If you'd like the setup done and handed over, our n8n workflow automation service can build a self-hosted instance in your name and hand over the server, database, backups, encryption key and runbook.

The decision rule

Price your upkeep hours before you price servers. If the n8n Cloud plan your volume needs costs less than the server plus those hours, use Cloud. If a requirement Cloud can't meet makes the choice for you, self-host, and put a name next to the monthly update before you rent the server. Not sure which side you're on? Send us your workflows and monthly volumes through the contact page, and we usually reply within one business day.