TL;DR
- Server: $12 to $30 a month. A 4GB virtual server runs a single n8n instance comfortably. Managed PostgreSQL adds roughly $15 a month if you do not want to run the database yourself.
- Your time is the real cost. Four to six hours to set up properly, one to two hours a month afterwards. At $60 an hour that is around $90 to $120 a month, which is several times the server bill.
- n8n Cloud Starter is €20 a month for 2,500 workflow runs and Pro is €50 for 10,000 (n8n pricing page, verified 21 August 2026). Below those volumes, Cloud is usually cheaper once your hours are counted.
- Self-hosting wins decisively above about 10,000 runs a month, because the Community Edition has no execution limit at all while Cloud pricing steps up sharply.
- n8n is not open source. It uses the Sustainable Use License, which n8n itself describes as fair-code rather than OSI-approved open source. You can run it internally and build workflows for clients. You cannot resell it as a hosted service.
If you have not yet settled on n8n as the platform, the billing-unit comparison in our n8n vs Zapier-vs-make guide is the decision to make first. This article assumes you have made it.
How much does it cost to self-host n8n?
Around $12 to $30 a month in infrastructure, plus your time. The software is free and the server is cheap. The hours are not.
| Cost line | Typical figure |
|---|---|
| Virtual server, 4GB RAM, 2 vCPU | $12 to $25 per month |
| Managed PostgreSQL database, optional | About $15 per month |
| Backups and storage | $2 to $5 per month |
| Domain and security certificate | Under $2 per month, certificate usually free |
| Infrastructure subtotal | $14 to $47 per month |
| Initial setup | 4 to 6 hours, one-off |
| Ongoing maintenance | 1 to 2 hours per month |
A virtual server, often called a VPS, is a slice of a computer in a data centre that you rent and control. PostgreSQL is a database, the thing that stores your workflows and your run history. You can run it on the same server for free or pay someone to manage it.
The number most guides stop at is the infrastructure subtotal. The number that decides the question is the one below it. At an internal cost of $60 an hour, one to two hours of maintenance is $60 to $120 a month, which is two to eight times the server bill.
That is the whole argument. Self-hosted n8n is free software running on a cheap server that you have to look after.
Is n8n actually free, and is it open source?
Free to run, yes. Open source, no. The distinction is legal rather than pedantic and it is widely misreported in both directions.
n8n uses the Sustainable Use License. n8n's own documentation is explicit about what that means: because the Open Source Initiative holds that open source licences cannot include limitations on use, and this licence does, n8n does not call itself open source. The company uses the term fair-code instead, describing software that is free to use, has source code openly available, can be extended by anyone, and is commercially restricted by its authors.
The history explains the shape. n8n launched under Apache 2.0, a fully permissive open source licence, in 2019. It moved to the Commons Clause in 2020 and to the current Sustainable Use License in 2022, each time to stop large companies repackaging the code as a competing hosted service.
What you can do:
- Run n8n inside your own company for your own purposes, at any scale, for free.
- Build workflows for clients and charge for it. n8n explicitly lifted the restriction that previously covered this. Its documentation states you are now free to offer commercial consulting or support services, such as building n8n workflows, without needing a separate licence agreement.
- Read, modify and extend the code.
What you cannot do:
- Host n8n for other people as a service. That is the restriction the licence exists to enforce.
- Embed n8n inside a commercial product you sell, without a separate agreement.
- Use the enterprise code. Files containing .ee. in the filename or .ee in the directory name are not covered by the Sustainable Use License and require an n8n Enterprise Licence.
The correction worth noting: a number of articles still say agencies need a licence agreement to build n8n workflows for clients. According to n8n's own documentation, that restriction was lifted. If this affects a commercial decision, read the licence yourself rather than trusting any summary, including this one.
Self-hosted or n8n Cloud: which is cheaper for you?
Cloud, until roughly 10,000 workflow runs a month. Then self-hosting wins and keeps winning.
n8n Cloud prices, from the official pricing page verified on 21 August 2026: Starter €20 a month for 2,500 executions, Pro €50 a month for 10,000, and Business €667 a month for 40,000, where an execution is one complete run of a workflow no matter how many steps it contains. The self-hosted Community Edition has no execution limit.
Worked example: three volumes
Illustrative figures. Internal cost assumed at $60 an hour, maintenance at 1.5 hours a month, server at $20, backups at $3. Euro figures converted at roughly $1.10 for comparison.
| Monthly runs | Self-hosted, infrastructure only | Self-hosted, including 1.5 hours | n8n Cloud | Cheaper option |
|---|---|---|---|---|
| 2,000 | $23 | $113 | ~$22 (Starter) | Cloud, by a wide margin |
| 8,000 | $23 | $113 | ~$55 (Pro) | Cloud |
| 25,000 | $23 | $113 | Above Pro; next self-serve tier is Business at ~$734 | Self-hosted |
| 100,000 | $30 | $120 | Enterprise, quoted | Self-hosted, decisively |
Read the first two rows. At ordinary business volumes, self-hosting is roughly twice the cost of n8n Cloud once you price the hours, and that is before counting the setup time or a single incident.
Read the third row. Above the Pro plan's 10,000 executions, the next self-serve step is a large one, while self-hosted stays flat. That is where the maths flips, and it flips hard.
The one-off costs
- Setup: 4 to 6 hours, so $240 to $360 at the same rate.
- The first incident: budget a day. Everyone has one.
Run this with your own hourly figure. If your time genuinely costs you nothing, for instance a personal project or a technical founder who enjoys it, the arithmetic changes completely and self-hosting is cheap at any volume. Be honest about which of those you are.
What do you need before you start?
Time required: 4 to 6 hours for a production setup, or about 20 minutes for a test instance you will later rebuild.
You need:
- A virtual server with at least 2GB RAM, though 4GB is the sensible minimum for real workloads. n8n uses more memory than people expect when workflows handle large files.
- Docker and Docker Compose installed. Docker is software that runs applications in isolated containers, so you do not have to install n8n's dependencies by hand.
- A domain name pointing at your server, needed for webhooks and for a security certificate.
- A reverse proxy such as Caddy, Traefik or nginx, which sits in front of n8n and handles encrypted connections.
- Somewhere to store secrets that is not a file committed to version control.
You do not need: Redis, unless you are scaling to queue mode. A single n8n instance with PostgreSQL runs fine without it.
How do you set up self-hosted n8n?
Eight steps. Steps 2 and 3 are the ones that prevent the disasters in the next section, so do them before your first launch rather than afterwards.
Step 1. Provision the server
Create a virtual server with 4GB RAM running a current Linux distribution. Install Docker and Docker Compose. Point your domain's DNS at the server's IP address.
Step 2. Generate and store the encryption key, before first launch
Generate a long random string and store it in your secret manager. This becomes N8N_ENCRYPTION_KEY.
Do this now, not later. If you skip it, n8n generates its own key on first launch and writes it into the ~/.n8n directory. Section 6 explains why that is the single most expensive mistake available to you.
For containers, prefer N8N_ENCRYPTION_KEY_FILE pointing at a mounted secret file, so the plaintext key never appears in your docker-compose.yml.
Step 3. Use PostgreSQL, not the default
n8n defaults to SQLite, a single-file database that is fine for testing and unsuitable for production because it locks the whole file on writes and cannot be backed up safely while running.
Set these environment variables:
DB_TYPE=postgresdb
DB_POSTGRESDB_HOST=your-db-host
DB_POSTGRESDB_PORT=5432
DB_POSTGRESDB_DATABASE=n8n
DB_POSTGRESDB_USER=n8n
DB_POSTGRESDB_PASSWORD=your-secure-password
Note the exact value postgresdb. Writing postgres is a common error: n8n starts normally, appears to work, and quietly uses SQLite anyway. Check your startup logs to confirm which database it actually connected to.
MySQL and MariaDB support was deprecated in n8n v1.0, so PostgreSQL is the only sensible choice for a new deployment.
Step 4. Set the webhook URL and proxy settings
If n8n sits behind a reverse proxy, which it should, set WEBHOOK_URL to your public HTTPS address and set N8N_PROXY_HOPS to the number of proxies in front of it. Without these, n8n generates webhook URLs pointing at its internal address and every incoming webhook fails.
Step 5. Set the timezone
Set GENERIC_TIMEZONE to your timezone. The default is America/New_York, so every scheduled workflow fires on New York time until you change it. This one is discovered at an inconvenient hour.
Step 6. Set an execution timeout and pruning
Set EXECUTIONS_TIMEOUT to a sensible number of seconds. Without it, a stuck workflow runs indefinitely, consuming memory until the server falls over.
Execution pruning is enabled by default with documented thresholds. Confirm the values suit your retention needs, because run history and file data grow faster than anyone expects.
Step 7. Mount persistent storage
Map a persistent volume for the ~/.n8n directory even when using PostgreSQL. n8n's documentation is explicit that the directory still holds encryption keys, instance logs and source control assets. Also mount a volume for your database if you are running it yourself.
Step 8. Put a reverse proxy in front and get a certificate
Caddy obtains and renews certificates automatically with minimal configuration. Traefik is the option n8n's own Docker Compose example uses. Either is fine. Do not expose n8n directly to the internet without encryption.
Then set up backups before you build anything you would miss. A daily database dump plus a copy of your encryption key, stored somewhere other than the same server.
The nine gotchas that break self-hosted n8n
In rough order of how badly each one hurts.
1. Losing N8N_ENCRYPTION_KEY. Every credential n8n stores is encrypted with this key. If you never set it, n8n generates one and writes it into ~/.n8n/config. Run the container without a persistent volume for that directory, restart, and the key is gone. There is no recovery mechanism. Your workflows survive; every API token, password and connection inside them becomes permanently unreadable and must be re-entered by hand. This is the most common self-hosting disaster and it is entirely preventable in step 2.
2. Running SQLite in production. Symptoms are a slow editor, execution timeouts and database lock errors in the logs. The fix is migrating to PostgreSQL, which is an hour of work now and a much longer job after corruption.
3. Setting DB_TYPE=postgres instead of postgresdb. n8n starts, appears healthy, and uses SQLite. Nothing warns you. Check the startup logs.
4. No persistent volume. Containers are disposable by design. Without mounted volumes, a restart discards your database file and your encryption key together.
5. Wrong or missing WEBHOOK_URL. Webhooks resolve to an internal address that nothing outside the server can reach, so every inbound trigger fails silently from the sender's point of view.
6. Default timezone. GENERIC_TIMEZONE defaults to America/New_York. Scheduled workflows fire on New York time and date calculations are out by hours.
7. No execution timeout. A single stuck workflow consumes memory until the machine runs out. Set EXECUTIONS_TIMEOUT.
8. Unbounded database growth. Run history and stored files accumulate. Pruning is on by default; confirm the thresholds match what you actually need to keep.
9. Skipping the security defaults. Set N8N_BLOCK_ENV_ACCESS_IN_NODE=true so workflows cannot read your server's environment variables, and use NODES_EXCLUDE to remove nodes such as Execute Command from users who do not need them. For sensitive deployments, put the editor behind a VPN or an IP allowlist at the proxy.
The pattern: eight of these nine are configuration decisions made in the first hour that only reveal themselves weeks later. That is the actual difficulty of self-hosting, and it is why the maintenance-hours line in section 1 is not padding.
When should you scale to queue mode?
When one instance stops keeping up, which usually shows as executions queuing behind each other rather than as an error message.
Queue mode splits n8n into a main process that handles the editor and incoming triggers, and separate worker processes that actually run the workflows. Jobs pass between them through Redis, an in-memory store used here as a job queue.
Three requirements, all from n8n's own documentation:
- PostgreSQL 13 or later. n8n explicitly does not recommend queue mode with SQLite. If you are still on SQLite, treat this as a migration project rather than a configuration change.
- Redis, reachable by every process.
- The same N8N_ENCRYPTION_KEY on the main instance and every worker. Workers read credentials from the database themselves, so without the shared key they cannot decrypt anything.
Queue mode is a scaling tool, not a fix for badly built workflows. If executions are failing rather than queuing, the problem is upstream.
When is self-hosting the wrong answer?
Five situations. Three of them are common.
Your volume is under 10,000 runs a month. The arithmetic in section 3 says Cloud is cheaper once your hours are counted. Self-hosting at low volume buys control, not savings, and control has to be worth something specific to you.
Nobody owns the server. Self-hosting means someone is responsible for updates, monitoring, backups and the outage. If that person is not named before you start, the cheaper option becomes the more expensive one the first time something breaks at an awkward moment.
You need the governance features. Single sign-on, Git-based version control and separate test and live environments are not in the Community Edition. Self-hosting with those features means the Business plan at €667 a month, which is a different decision entirely.
You are self-hosting to avoid vendor lock-in but running one instance with no backups. That is not independence, it is a single point of failure you now own personally.
You want to host it for clients. The licence does not permit offering n8n as a service to other people. Building workflows for clients on infrastructure they own is fine.
Where self-hosting is clearly right: high execution volume, data that cannot leave your own infrastructure for regulatory or contractual reasons, an existing operations team who already run servers, or a genuine need to modify the software.
How does Euracle decide hosting for clients?
The hosting question gets answered with the client's own hourly rate in the room, and the answer is Cloud more often than agencies tend to admit.
The Eureka Method, Euracle's discovery sprint, applies four steps here.
Discover counts expected monthly executions from the actual workflow list rather than estimating, because that single number decides most of this.
Design runs the comparison in section 3 using the client's real internal cost per hour, and names who will own the server if the answer is self-hosted.
Deploy builds on PostgreSQL with the encryption key set before first launch, persistent volumes mounted, and backups configured before the first workflow is written.
Scale reviews execution volume quarterly, since the crossover point moves as usage grows.
The stack is deliberately conventional: Docker and Docker Compose, PostgreSQL, AWS or a comparable provider, and a reverse proxy handling certificates automatically. Nothing exotic, because the person maintaining it in two years may not be the person who built it.
Two structural commitments come from how Euracle is set up. Senior practitioners only: the people in the pitch do the work, which matters here because seven of the nine gotchas above are things you only avoid if you have hit them before. And one contract across six disciplines, so a finding that the client needs a hosting decision, a process change and someone to own the server does not require three conversations.
If you want that arithmetic run on your numbers before committing to either option, that is Euracle's workflow automation service. The data-residency version of this question comes up most often with IT services companies, where client contracts frequently dictate where data may sit.
If the workflows you are planning involve judgement rather than fixed steps, the hosting question changes shape, and our AI agents for business guide covers what that adds.
FAQ
Conclusion
You can now answer the hosting question with arithmetic instead of instinct. Count your expected monthly executions, price your own maintenance hours honestly, and compare that against n8n Cloud's published tiers. Below roughly 10,000 runs a month, Cloud usually wins on cost and you should be able to name what control is buying you. Above it, self-hosting wins clearly. If you do self-host, set the encryption key before first launch, use PostgreSQL, mount your volumes and configure backups before you build anything you would miss. If you want that comparison run on your own numbers first, talk to Euracle about workflow automation.
Sources
- n8n, official pricing page, verified 21 August 2026. Cloud tier prices, execution definition, Community Edition self-hosting. https://n8n.io/pricing
- n8n Docs, Sustainable Use License. The fair-code description, the statement that n8n does not call itself open source, and the lifting of the consulting and support restriction. https://docs.n8n.io/sustainable-use-license/
- n8n, LICENSE.md in the public repository. The exclusion of files containing .ee. in the filename or .ee in the directory name from the Sustainable Use License. https://github.com/n8n-io/n8n/blob/master/LICENSE.md
- n8n Docs, environment variable and Docker installation documentation, on the ~/.n8n directory holding encryption keys, instance logs and source control assets even when PostgreSQL is in use.
- n8n Docs, Configuring queue mode, on PostgreSQL 13 or later, Redis, and sharing the encryption key with all workers.
- Licence history: Apache 2.0 in 2019, Commons Clause in 2020, Sustainable Use License in 2022.
- Virtual server and managed database pricing ranges, August 2026.
