How to Self-Host n8n: Docker, npm, and the Community Edition
Self-hosting n8n puts the entire workflow automation platform on infrastructure you control: your data, your network, your security boundary. This guide walks through the two supported install paths, Docker and npm, shows you how the free Community edition relates to the paid Business and Enterprise editions, and explains queue mode for when a single process is no longer enough. It also covers the part most tutorials skip: deciding whether you should self-host at all.
What you will end up with: a running n8n instance with its editor at http://localhost:5678, data persisted across restarts, and a clear sense of when to move from a single container to a queue-mode cluster.
Should You Self-Host?
Self-hosting gives you maximum privacy and control. Your workflows, credentials, and the data flowing through them never leave infrastructure you own. For teams with compliance requirements or sensitive data, that is the whole point.
The tradeoff is operational responsibility. n8n is direct about this: self-hosting requires server, scaling, and security expertise, and the vendor recommends its managed Cloud offering for people who do not want to own those tasks. If nobody on your team is comfortable patching a server, configuring a reverse proxy with TLS, and planning for backups, Cloud is the honest answer rather than a half-maintained box.
Run through the checklist below before you install. Every item is something you, not n8n, will own once the instance is live.
Install with Docker
Docker is the most common way to self-host n8n. It keeps the runtime and its dependencies isolated from the host, and a named volume keeps your workflows and credentials intact when the container is recreated.
Step 1: Create a named volume
The volume is where n8n stores its database, encryption key, and saved credentials. Create it once so this state survives container restarts and image upgrades.
Step 2: Start the container
This command runs n8n in the foreground, maps the editor port, and mounts the volume you just created at the path n8n reads on startup.
The -p 5678:5678 flag exposes the editor on port 5678, and -v n8n_data:/home/node/.n8n mounts the volume so nothing is lost when the container stops. The --rm flag removes the container on exit; the data stays in the volume, not the container, so this is safe.
Step 3: Open the editor
Open http://localhost:5678 in a browser. You will be prompted to create an owner account, and from there you are in the visual editor building workflows.
Heads up on the encryption key: n8n generates an encryption key on first run and stores it in the volume. If you lose the volume, you lose access to the credentials it encrypted. Back the volume up the same way you would any database.
Install with npm
If you already have Node.js on the host and would rather not introduce Docker, n8n runs directly through npm. The quickest path uses npx, which fetches and runs n8n in one step without a separate global install.
Step 1: Confirm Node.js
n8n is a Node.js application, so a working Node.js install is the only prerequisite for this path. Check it first:
Step 2: Run n8n
A single command downloads n8n and starts it locally:
When the process finishes starting, the editor is available at the same address as the Docker path: http://localhost:5678. The npx approach is excellent for trying n8n on a laptop or in a quick test environment. For a durable install, run n8n under a process manager so it restarts cleanly and survives reboots.
Community vs Business and Enterprise
A common point of confusion: when you self-host n8n, which edition are you running? The answer depends entirely on whether a license key is present.
Without a license key, you are running the free Community edition. This is the edition whose source is published on GitHub. It is fully functional for building and running workflows, and it costs nothing. For many self-hosters, this is the whole product.
A Business or Enterprise license key unlocks those editions and their advanced features on the same self-hosted binary. You do not install a different product; you apply a key that the running instance reads to enable the additional capabilities tied to those paid tiers.
| Edition | How You Get It | Cost |
|---|---|---|
| Community | Self-host with no license key | Free |
| Business | Self-host plus a Business license key | $800/mo, billed annually (vendor-reported) |
| Enterprise | Self-host or n8n Cloud plus an Enterprise key | Custom (contact sales) |
The Business plan is positioned for organizations under 100 employees and adds capabilities such as SSO via SAML and LDAP, Git-based version control, and environments. A start-up plan for organizations under 20 employees is offered at half the Business price. Pricing here is vendor-reported and was verified on June 9, 2026; confirm current numbers at n8n.io/pricing before you budget.
Scaling with Queue Mode
A single n8n process handles a surprising amount of work, and most self-hosters never need more than that. When execution volume grows past what one process can keep up with, n8n offers queue mode to scale out horizontally.
In queue mode, the main n8n process no longer runs workflows itself. Instead it hands executions to a broker, such as Redis, and one or more dedicated worker processes pull jobs from that broker and run them. Adding more workers increases throughput, and because the workers are separate processes, a slow or failing workflow on one worker does not block the others.
When to reach for it: stay on the default single-process mode until you have evidence you need more, such as executions queueing up or the instance struggling under load. Queue mode adds moving parts (a broker plus workers) that you then have to operate and monitor.
Because queue mode changes your architecture, treat it as an infrastructure decision, not a config flag. You are introducing a broker as a new dependency, and your backup, monitoring, and deployment process all need to account for it. The current setup steps and environment variables live in the n8n hosting documentation, which is the right reference because flags can shift between releases.
The Self-Hosted AI Starter Kit
n8n has native AI capabilities, and they are available on self-hosted instances, not just Cloud, from version 1.19.4 onward. If you want to run AI workflows entirely on your own hardware, n8n publishes a self-hosted AI Starter Kit for exactly that.
The Starter Kit is a packaged starting point for running AI workflows locally, which fits naturally with the privacy motivation behind self-hosting in the first place. If your reason for self-hosting is keeping data in-house, running the AI side locally as well keeps that boundary intact rather than sending prompts and documents to a hosted model. As with the rest of the hosting setup, follow the current Starter Kit instructions in the official documentation for the exact components and commands.
Fair-Code and the Sustainable Use License
It is worth being precise about n8n's license, because "you can see the source and self-host it" leads people to assume it is open source. It is not, in the strict sense. n8n is fair-code.
The source is available under the Sustainable Use License (SUL) plus an n8n Enterprise License. n8n adopted this model in March 2022, replacing an earlier Apache 2.0 plus Commons Clause arrangement. The practical effect for a self-hoster: the SUL permits you to use, modify, and redistribute the software, but it restricts that use to internal business purposes. The advanced features tied to the paid editions still require a Business or Enterprise key even though the code is visible.
For most internal automation use cases, this distinction never causes friction. It matters if you are planning to offer n8n itself as a hosted service to others, which is precisely the scenario the SUL is written to limit. If your plans go beyond internal use, read the license terms directly rather than relying on a summary.
Troubleshooting
These are the issues self-hosters hit most often during setup, with the fix for each.