Should you self-host n8n? What it really costs

Usually because an invoice has grown faster than the value of the work behind it. Before moving anything, check that the bill reflects real work. n8n's documentation says paid plans, cloud or self-hosted, carry an execution quota, and that only production executions count towards it: a Schedule Trigger counts each time it fires, a webhook counts each inbound request, and a polling trigger counts only when it finds new data.

That makes the usual causes of a runaway count structural, and they follow you to your own server, where they stop showing up as money and start showing up as load. Fix them first.

1. 01A schedule firing every few minutes for data that changes twice a day. Move to a webhook, or widen the interval to match reality.
2. 02One inbound request per record where the source system could send a batch. Each webhook request is an execution, so a batch endpoint and one run is cheaper than many.
3. 03An iterator running over a whole table because writing the filter was harder than omitting it. Items inside one execution do not add to the count, but they add run time and memory, which is the load you inherit on your own server. The filter belongs in the query, not in a downstream condition.

Beyond the infrastructure, the cost is people's time: upgrades, credential rotation, restore tests and incident response. Price the infrastructure from your host's current quotes, and price the time from what an hour of the person doing it costs you. No figure is written here because yours will differ.

The free self-hosted edition is licensed under n8n's Sustainable Use License, a source-available 'fair-code' licence rather than a standard open-source one. In n8n's own words it permits use for your own internal business purposes or for non-commercial or personal use. Its FAQ says building automations for clients on your instance is allowed as long as the clients cannot create or edit the workflows, and that hosting n8n as a service for clients to build their own workflows is not. Some features are not in the free Community edition, including single sign-on, environments and external secret stores, and n8n says they come with its Business and Enterprise plans. Custom roles are an Enterprise feature. n8n also states that its pricing page is the source of truth for what each plan includes, so check it and the licence before assuming self-hosted means free.

Break-even, with the working

Self-hosting pays only when the monthly saving is positive. Monthly saving = hosted bill − (hosting + maintenance hours × your hourly cost). Hosting is what your provider charges for the machine, database, backups and monitoring. Maintenance hours are the time you spend on upgrades, restore tests, credential rotation and incidents. Your hourly cost is what an hour of the person doing that work costs the business.

1. 01Take the last few months of the hosted invoice and use the typical month, plus the highest, so a spike does not decide it.
2. 02Get a current quote for the hosting you would actually need, including backups and monitoring.
3. 03Measure your own maintenance hours. If you already run one internal server, log the time it takes for a month. If you do not, treat the first quarter as a trial and track hours from day one.
4. 04Multiply the hours by an honest hourly cost, then subtract the total from the hosted bill. If the result is small or negative, or is wiped out by one failed upgrade, stay hosted.

Pin an exact version, test each upgrade on a staging instance, and take a database backup first. n8n recommends keeping a self-hosted instance up to date for the latest features and fixes, which makes upgrading part of the running cost. The gap to the current version also gets harder to close the longer it is left.

• Pin an exact version tag. Running a floating latest tag means an unplanned upgrade every time the container restarts: untested software deployed on a schedule you do not control.
• Take a full backup before every upgrade, as n8n's own documentation recommends. Treat the backup as the way back if an upgrade goes wrong, and test that you can restore it.
• Keep a staging instance with copies of the workflows and non-production credentials. It is the difference between finding a breaking node change on a quiet afternoon and finding it in your busiest hour.
• Read release notes for breaking changes rather than skimming for features, and upgrade on a regular cadence. The team that has not upgraded in a year is the team that cannot.

It is the key n8n uses to encrypt credentials before saving them to the database. n8n's documentation says that without the key, a restored database cannot be decrypted, so the workflows can come back while every connection is unreadable. By default n8n creates a random key on first launch and saves it in its user folder (~/.n8n by default); you can supply your own with the N8N_ENCRYPTION_KEY environment variable instead. It catches people who did everything else right.

What to do about it

• Set the key explicitly, from your own secret store, rather than letting the instance generate one you have never seen. Back it up somewhere that is not the database backup. If you later run queue mode, every worker needs the same key as the main instance.
• Treat who has an account on the instance as a security decision. Anyone who can build workflows can make them use the credentials they can reach, so grant access deliberately.
• Never paste a token into an HTTP node header. It then lives in the workflow body, travels with every export, appears in every screenshot, and cannot be rotated without editing each place it was pasted. We built a scan-and-extract action into Blueprint Runner for exactly this reason: exported Make blueprints carried hard-coded bearer tokens, which made them unsafe to share or commit.
• Keep scheduled work's secrets where the scheduler runs. In FlowForge, our own workflow runner, shared secrets moved from browser storage to server-side storage because a scheduler has no browser to read them from.

Back up three things together: the database, the n8n user folder that holds the encryption key, and your deployment configuration, including any environment variables and external storage you use. Then restore them onto a fresh instance once and confirm a workflow runs. n8n's documentation is explicit that without the key, a restored database cannot be decrypted, so any one of the three missing makes the others much less useful.

SQLite is n8n's default database, and n8n's documentation advises stopping n8n before copying a SQLite database file, or using a tool that takes a consistent snapshot, because copying it mid-write can give an inconsistent backup. For anything you depend on, use Postgres, which n8n supports, and back it up with its own tooling. Export workflows as JSON into a repository as well. That is not real version control, but it is far better than no history.

When executions start blocking the editor, or webhook bursts arrive faster than one process can handle them. By default (regular mode) a single n8n instance runs its own executions, and n8n's documentation warns that too many concurrent production executions can cause performance degradation and unresponsiveness. The symptom of outgrowing it is a sluggish editor and executions queueing for no obvious reason.

In queue mode the main instance handles triggers and webhook calls and passes each execution to Redis, which holds the queue of pending executions. Workers pick executions up, run them and write the results to the database, and you can add or remove workers as load changes. n8n does not recommend queue mode with SQLite, so plan on Postgres. Every worker must share the main instance's encryption key. It is also a real change in footprint: another service to run, another thing that can be down, and a new failure mode where the queue is healthy and the workers are not. Move deliberately, not during an incident.

If the answer is 'nobody until a customer asks', either the automation is not load-bearing or self-hosting has just added an on-call duty to somebody's job. When the instance stops at eleven on a Friday night, who finds out, how, and how quickly? That test has nothing to do with money, and it is the real price of running it yourself.

What to wire up

• An uptime check that alerts somewhere a person looks. n8n exposes a /healthz endpoint that returns 200 when the instance is reachable, and /healthz/readiness, which also confirms the database is connected and migrated. Add an error workflow that catches failed executions with enough context to diagnose without opening the editor.
• A heartbeat on anything scheduled. A workflow that should run hourly and has not run in three hours has failed even though nothing errored, and it will never appear in an error list.
• Disk and memory alerts. A full disk and a workflow that loaded a large file into memory are two ways an instance can die.
• A runbook: where it runs, how to restart it, where the backups and the key are, and who to call. If one person holds all of that in their head, you have a different problem.

That last row is the option most people miss. Self-hosting is not all-or-nothing: the sensible shape is often to leave the long tail of low-volume automations on the hosted platform the team already understands, and take only the expensive workflow onto infrastructure you control. The same logic is why we built Blueprint Runner, an engine that executes Make blueprint JSON natively: so that per-operation pricing stops being a reason to rewrite logic that already works.

Whichever way you go, treat the instance as a system you run rather than an app you installed. Otherwise it becomes a container on a forgotten machine holding credentials nobody can rotate, a worse position than the invoice you were escaping.