How to self-host n8n (and what the licence actually says)

n8n is the best-known workflow automation tool and one of the most misunderstood licences in the category. Here is what running it yourself actually involves, and a straight answer on what you are and are not allowed to do with it.
The licence, first, because it decides everything else
n8n is source-available, not open source in the OSI sense. It ships under the Sustainable Use License, which permits use for your own internal business purposes and for non-commercial purposes, and restricts providing the software to others for a fee.
In plain terms: running n8n for your own company’s automations is explicitly allowed, including commercially. Selling managed n8n hosting to third parties is the case the licence is written about. That is why this site documents n8n and does not sell it — and why we can still recommend you self-host it for your own use without hesitation.
If you are a consultancy running n8n on behalf of clients, that is the grey area. Ask n8n directly and get the answer in writing; it is a short email against a real risk.
What n8n needs in production
The Docker image is the normal route, with a few decisions that separate a demo from something you can rely on:
A real database. The default SQLite is fine for trying it and a liability under load or with concurrent executions. Point it at Postgres before you build anything important.
Persistent storage. Workflows, credentials and execution history all live on disk. A container without a volume loses everything on the first update.
The webhook URL. This is the single most common support question in the community. n8n builds webhook URLs from its configured host, so behind a reverse proxy it must be told its public address explicitly. Get this wrong and webhooks register against an internal hostname that nothing outside can reach.
Execution data pruning. Execution history grows without limit by default. On a busy instance it fills the disk, and the failure looks like a database problem rather than a housekeeping one.
Encryption key continuity. Credentials are encrypted with a key that must persist across restarts and be included in backups. Lose it and every stored credential has to be re-entered.
Security, because it holds every key you own
An automation platform accumulates credentials for everything it touches — CRM, email, database, payment processor. Treat the instance accordingly: authentication on from the first boot, TLS always, no public execution endpoints, and restraint about who gets an account.
The same goes for anything you connect through it. A workflow with a shell or HTTP node is, functionally, remote code execution with your credentials attached.
Sizing
n8n is not heavy at rest. Two gigabytes runs a modest instance; four is comfortable once Postgres and a handful of concurrent executions are involved. What actually drives resource use is what your workflows do — a node that processes large files or runs a browser dwarfs the base footprint.
If you are coming from n8n Cloud, note what you are escaping: the hosted plans meter executions, so a workflow that runs constantly is exactly the one that costs most. Self-hosting makes throughput a sizing question instead.
If you would rather not run it
We do not sell managed n8n, for the licence reason above. What we do host are the four platforms that are licensed for it: Activepieces, which is the closest substitute in feel and has an MIT community edition; Windmill for teams who would rather write a function; Node-RED for event and device work; and Kestra for scheduled pipelines that belong in version control.
If n8n itself is non-negotiable, run it yourself — that is permitted — and we will happily host the rest of the stack beside it.
Related reading
Questions
Is n8n free for commercial use?
Can I use n8n for client work?
Why do other hosts sell managed n8n?
What is the closest alternative?
Put your AI stack on your own box
Pick an app, pick a size, and have it running today. Month to month, cancel whenever.