Somebody in the team has found n8n, built a working CRM automation in an evening, and is now asking to move everything onto it. The demo is genuinely impressive. The question that decides whether this is a good idea does not appear anywhere in the demo.
n8n is a workflow automation tool: a canvas of connected nodes, a few hundred integrations, triggers on schedules and webhooks. In that description it sounds like every other tool in the category. The difference is that you can run it on your own machine, and almost everything interesting about it — the good and the awkward — follows from that one fact.
What "fair-code" means, and what it does not
n8n is not open source in the OSI sense, and this trips people up who read "self-hostable" and assume MIT.
The code is source-available under what n8n calls a Sustainable Use Licence. In practice: you can run it internally for your own business, modify it, and never pay anything. What you cannot do is take it and offer it to third parties as a hosted service. If you are an agency planning to spin up an n8n instance per client and charge them for access to it, read the licence properly before building the business model — that is precisely the case it is written to restrict, and n8n sells an embed/enterprise licence for it.
For a company automating its own operations, none of this bites. For anyone whose plan involves reselling, it is the first thing to check, not the last.
Self-hosting is a real commitment, and it is not one container
The five-minute Docker command in the docs is genuinely five minutes. It is also not what you want in production, because it defaults to SQLite storing everything on a local volume.
A production shape looks like this:
| n8n Cloud | Single container | Queue mode | |
|---|---|---|---|
| You operate | Nothing | Container, database, backups, upgrades | All of that plus Redis and workers |
| Database | Managed | Postgres — do not stay on SQLite | Postgres |
| Concurrency | Handled | One process, blocking on long runs | Scales by adding workers |
| Cost shape | Per execution | Per server, flat | Per server, several of them |
| Data leaves your network | Yes | No | No |
| Right when | Low volume, no data constraint, small team | Steady internal volume, someone owns ops | High volume or long-running jobs |
Two operational details that catch people out and are worth knowing before rather than after.
Execution data grows without limit by default. Every run stores its input and output payloads. A workflow firing every minute against a chatty API will fill a disk faster than anyone expects. There are EXECUTIONS_DATA_PRUNE settings for exactly this — turn them on before you need them, not during the incident.
Encryption key loss is unrecoverable. Credentials are encrypted at rest with a key n8n generates on first run. Lose the volume holding it and every stored credential becomes undecryptable. Back it up somewhere other than the machine it lives on.
The code node is where the tool stops being no-code
Most automation platforms give you a formula box. n8n gives you a node containing real JavaScript — and, more recently, Python — operating over the whole batch of items flowing through.
This is the single feature that decides whether n8n fits your problems. Data work between business systems is mostly reshaping: joining two API responses, normalising inconsistent enum values, collapsing duplicates, deciding which of three sources wins for a given field. In a strictly no-code tool that becomes ten branching nodes and a diagram nobody can read. In a code node it is fifteen lines you can review in a pull request.
The trap is the obvious one. A workflow that is one visual node containing four hundred lines of JavaScript is not an automation any more — it is an application, deployed through a UI, with no tests and no code review. If a code node is getting long, the work has outgrown the canvas. That is a signal to move it into a real service, not to keep going.
Where it fits against the CRM
The common shape is a CRM as the system of record with n8n doing the joining: enriching a contact on creation, pushing a closed-won deal to finance, routing a new lead to the right owner, reconciling two systems nightly.
That works well, and it works well specifically because you can hold the logic where a person can read it. The failure mode is the same as with any workflow tool, and it is not a tool problem: state ends up living in the workflow rather than on the record. A nightly sync with no synced_at column will happily reprocess everything it has already done the first time somebody rebuilds it. We wrote about why that column belongs in the database rather than in the automation, and it applies here regardless of which tool you pick.
When cloud is the cheaper answer
Self-hosting is free in licence terms and not free in any other sense. The honest arithmetic:
Self-host, single container
Cheap, quiet, easy to keep patched. The common good case.
Self-host, queue mode
Where per-execution pricing genuinely stops making sense.
Cloud
Paying to not have a server is correct here. Do not fight it.
Cloud, and revisit
The bill will get your attention eventually. Plan the migration before it does.
If nobody on the team wants to own a container, a Postgres instance, an upgrade cadence and a backup that has actually been restored once, then cloud is not a compromise — it is the right call, and self-hosting to save a subscription will cost more in the first outage than it saved in a year.
The case where self-hosting genuinely wins on money is high volume, because execution-based pricing scales with activity while a server does not. The case where it wins on something other than money is a data constraint: if customer records cannot leave your network for contractual or regulatory reasons, self-hosting is not an optimisation, it is the only option on the table.
Things worth knowing that the tour skips
Community nodes install from npm into your instance. Useful, and you are installing third-party code into the process that holds all your credentials. Read it, or pin it, or both.
There is a public API for managing workflows and executions, which means workflows can be exported as JSON and put in version control. Do this. A canvas edited directly in production with no history is a change nobody can review and nobody can revert.
The community forum is where the real answers are. The documentation covers node parameters well and covers "how do I structure this" less well. Search the forum first.
The check worth doing today
Before you decide anything, answer one question honestly: who upgrades it?
Not who builds the first workflow — that person is already keen. Who applies the security patch in four months, notices the disk filling, and restores from backup when the volume dies. If that person exists and has time, self-hosting is a good deal and the licence will not trouble you. If the honest answer is "nobody, we'd figure it out", pay for the cloud version and spend the saved attention on the workflows themselves, which is where the value was always going to be.
Common questions
- What is n8n?
- A workflow automation tool built around a canvas of connected nodes, with triggers on schedules and webhooks and a few hundred integrations. What distinguishes it from the hosted alternatives is that you can run it on your own infrastructure, and that it includes a code node running real JavaScript or Python rather than a formula box.
- Is n8n open source and free?
- It is source-available under n8n''s Sustainable Use Licence, which is fair-code rather than OSI open source. You can self-host and modify it for your own business at no cost. You cannot offer it to third parties as a hosted service — if your plan is an instance per client with a charge attached, that needs a commercial licence.
- Do I need Docker to run n8n?
- Docker is the usual route and the one the documentation leads with, though npm installation also works. The more important detail is that the default single-container setup stores everything in SQLite on a local volume, which is fine for trying it out and not what you want in production. Move to Postgres, and add Redis with worker processes if you need real concurrency.
- When should I pay for n8n Cloud instead of self-hosting?
- When nobody on the team will genuinely own the container, the database, the upgrade cadence and a backup that has been restored at least once. Self-hosting is free in licence terms only; the first outage costs more than a year of subscription. Self-hosting wins on cost at high execution volume, and wins outright when data cannot leave your network.
- What is the n8n code node for?
- Reshaping data between systems — joining two API responses, normalising inconsistent values, deciding which source wins for a field. It runs JavaScript or Python over the whole batch of items, which turns what would be ten branching visual nodes into a few readable lines. If a code node grows past a screen or two, the work has outgrown the canvas and belongs in a real service.
- n8n
- Automation
- Workflow design
- Self-hosting