đź’¬ Your view on a proposed change: requiring Docker to run n8n

Announcements
1

Up to now, there have always been two main ways of deploying n8n: via npm and via Docker. We are considering sunsetting npm-native support and would like to get your feedback on it.

We’d love it if you could fill out this survey after reading.

Why we’re considering this

We’re working hard on a much more powerful AI assistant - think Claude Code, but embedded into n8n. This has been top of the community’s wishlist for a long time, and it’s important that we bring this to self-hosted. We’re targeting a self-hosted release this summer.

For security, this assistant needs a sandbox. That sandbox needs to be deployed in a separate Docker container. This means that n8n will have a dependency on Docker. Because of this, it makes sense to standardise on a Docker-based deployment - particularly because it’s a more reliable deployment method anyway.

What this would mean for npm-based installs

If you wanted to upgrade, you’d need to make sure Docker is installed and deploy using that instead. You could still keep your installation in the same directory and mount that directory into Docker. We would provide guidance on how to do this.

If I don’t want the assistant, why couldn’t I keep running the rest of n8n via npm?

While this is technically possible, the more different flavors and configurations of a product one has, the more complexity and bugs one introduces.

There are other benefits to moving to Docker-only; the assistant is just the most immediate one. Doing so would:

  • Speed up development of n8n
  • Make n8n easier to support
  • Open the door to bundling other products with n8n in the future if we needed to, e.g. a vector database or Redis.

What we’d like to know

We’re aware that there may be some situations where using Docker is hard. n8n is used in all kinds of ways and some of them we’re likely not even aware of. So we’d like to hear from everyone about this topic, whether you currently use npm or Docker — please fill out the survey below! :folded_hands:

:backhand_index_pointing_right: Link to survey

11 Likes
3

I support this. Has been a long time since I used an npm install of n8n, other than when developing nodes.
Using npm for n8n installs will always lead to issues at some point. Docker is more secure as well.
When clients want us to manage their instance we always push them towards Docker if they are using npm. Makes everything easier to manage. :slight_smile:

12 Likes
4

I agree with Bram, docker is way easier to setup and it’s faster and it has containers so it can help keep stuff secure.

5 Likes
5

I support this direction. I run n8n myself in Docker and previously experimented briefly with npm. The difference in stability and maintainability is clear.

What convinces me about the decision: The embedded AI assistant needs a sandbox, and a sandbox needs Docker. This isn’t an arbitrary dependency but a technically justified one. Anyone using n8n seriously typically already has Docker running anyway.

The only point that gives me pause: There are users who run n8n in very lean environments, for example small VPS instances without much RAM, where Docker noticeably costs more resources than a bare npm installation. For them, clear migration guidance and ideally an optimized Docker image would be important.

All in all: Fewer variants means fewer bugs and faster development. That benefits the whole community.

3 Likes
6

Well, it s time to enter in the Docker rabbit hole CLI and Desktop tutorials.
If some wizzard can share a complete docker file with queue,workers,task runners, postgresql,redis example… we can definetly stop npm lovers from doing it again in the future :slight_smile:

P.S some loves npm… some loves docker… but more important is that EVERYONE loves N8N!!!

1 Like
7

I agree: Docker feels like the cleaner and more maintainable path here, especially for the AI assistant sandbox and long-term stability.

1 Like
8

Upgrading from npm was a nightmare. There were a lot of dependency issues.
Docker is easier although it comes with some overheads. Managability is the key.

+1 for Docker

1 Like
9

Supportive of this direction. From running n8n on VPS instances for multiple client environments, Docker has been significantly more predictable than npm across n8n versions - especially when the AI sandbox started requiring separate process isolation.

The one concrete request I’d add: a minimal single-container Compose file optimized for small VPS (1-2 vCPU, 1-2 GB RAM) with clear documentation on which services can be disabled to reduce overhead. A lot of self-hosted users run n8n on budget VPS where the Docker daemon itself adds memory pressure, so guidance on the minimum viable Docker setup would reduce friction for those migrations.

4 Likes
10

I’m running Docker on an Ubuntu VPS via MobaXterm. This method is a bit technical, but anyone who’s used it before will likely prefer it in the long run.
Docker Compose + Cloudflare Tunnel is an essential setup for users - quite easy to back up, maintain, and even migrate data.
The requirement for a sandbox environment for the AI assistant is just an added benefit.

However, does the current Docker Compose setup need any changes when the assistant is launched? Or is it just an additional container that plugs into and runs on the same system?

11

Should just be an extra container, yes :+1:

2 Likes
12

Thanks for the transparency on this. I agree that there are benefits to moving to Docker but a few technical challenges as well, including access to local files and allowing command like operations like creating folders and files. This works with multiple adjustments today and will become even more complex with the addition of Docker in the mix.

Another part that might complicate things is the docker licensing itself and what that means for some users.

13

Very good idea, plus the npm hacking name has grown, so it can damage one’s data when working in n8n. And to install n8n in docker requires technical knowledge, but one can learn, I myself had problems installing n8n in docker desktop but I solved it step by step by searching on YouTube and asking the Chinese AI Deepseek.

14

supported, questionnaire completed

1 Like
15

Fortunately, Coolify makes Docker more user-friendly. File access remains something not easy to handle.

1 Like
16

Running self-hosted n8n for a SaaS platform with multiple tenants - fully support Docker-first. Everything about the multi-worker, queue-mode setup works more reliably when the n8n version and runtime environment are consistent across main, workers, and webhooks containers. npm-based installs drift on the host OS level and cause subtle differences between environments that are hard to debug. The AI assistant sandboxing requirement is just the natural endpoint of a direction that was already the right call for production deployments.

17

That’s disappointing news - I’m not (yet :wink: an expert but I did try using Docker and it brought my machine to a standstill (Windows 16Gb RAM with n8n installed locally). When I uninstalled Docker and went back to using NPM I could get on with real work on n8n instead of spending time down resource rabbit holes. Yes I could upgrade my machine however some of my clients have more basic setups and I sometimes need to work with what they’ve got.
From my (albeit limited) perspective, using Docker seems to add an unnecessary layer of complexity and overhead for simple situations. If Docker must be pursued for technical reasons, does it have to be so greedy?

1 Like
18

In my opinion, even non-administrators can install Docker, and thanks to tools like Portainer, it’s also easy to manage. This makes it easier for beginners (like me) who don’t want a cloud solution to get started.

Having multiple options often leaves many people facing a dilemma when making a decision. Sometimes it’s good to have the decision made for you (I’m referring here to users who just want to try out an installation).

I’m excited about the idea of an AI assistant, and I’m sure it will help n8n make great strides.

Survey finished? Done :wink:

1 Like
19

I’m on board with the Docker-only direction for most users, and a lean, hardened, non-root default image makes sense. But it has two properties that make it hard to run well on NAS/self-hosted hosts (Unraid, Synology, …), and going Docker-only turns these from “just use npm” into hard blockers:

  1. No host UID/GID mapping. The image runs as a fixed node user (uid 1000), so bind-mounted shares end up owned by the wrong UID/GID on the host. The established fix (LinuxServer.io images and friends) is to start as root, do first-run setup, then drop to a user remapped from host-provided PUID/PGID - so the container never clobbers share permissions.

  2. No package manager (apk is removed). Some NAS integrations need root + a package manager at first run - e.g. Unraid’s Tailscale integration uses a hook that installs and configures Tailscale at container start, impossible once apk/apt is stripped.

Importantly, (1) can’t just be an env flag on the current image: UID remapping (chown of mounted data, usermod, dropping via su-exec/gosu) fundamentally requires the container to start as root. That’s a deliberate posture change from the hardened non-root default - which is exactly why I think this belongs in a separate image rather than weakening the default.

So: would the team consider an officially-maintained self-hosted/NAS variant - e.g. n8nio/n8n:<version>-nas - that starts as root, remaps to host PUID/PGID, drops privileges, and keeps a package manager available for first-run hooks? The hardened default stays exactly as-is for everyone else.

1 Like