💬 Deine Meinung zu einer vorgeschlagenen Änderung: Docker als Voraussetzung für n8n

[sirdavidoff]

Bislang gab es immer zwei Hauptwege, n8n einzusetzen: via npm und via Docker. Wir erwägen, den nativen npm-Support auslaufen zu lassen, und möchten gerne dein Feedback dazu erhalten.

Wir würden uns freuen, wenn du nach dem Lesen diese Umfrage ausfüllen könntest.

Warum wir das erwägen

Wir arbeiten an einem viel stärkeren KI-Assistenten – stell dir Claude Code vor, aber in n8n eingebettet. Das stand lange Zeit auf der Wunschliste der Community, und es ist wichtig, dass wir das auch für Self-Hosted verfügbar machen. Wir planen eine Self-Hosted-Veröffentlichung für diesen Sommer.

Aus Sicherheitsgründen braucht dieser Assistent einen Sandbox. Dieser Sandbox muss in einem separaten Docker-Container eingesetzt werden. Das bedeutet, dass n8n eine Abhängigkeit von Docker hat. Deshalb macht es Sinn, auf Docker-basierte Einrichtungen zu standardisieren – zumal das eh eine zuverlässigere Deployment-Methode ist.

Was das für npm-basierte Installationen bedeuten würde

Wenn du updaten möchtest, müsstest du sicherstellen, dass Docker installiert ist, und stattdessen damit einsetzen. Du könntest deine Installation trotzdem im gleichen Verzeichnis behalten und dieses Verzeichnis in Docker einbinden. Wir würden dir Anleitung geben, wie du das machst.

Wenn ich den Assistenten nicht möchte, warum könnte ich den Rest von n8n nicht weiterhin via npm betreiben?

Whilte das technisch möglich ist, gilt: Je mehr verschiedene Varianten und Konfigurationen ein Produkt hat, desto mehr Komplexität und Bugs entstehen.

Es gibt andere Vorteile beim Umstieg auf Docker-only; der Assistent ist nur der unmittelbarste. Das würde Folgendes mit sich bringen:

• Schnellere Entwicklung von n8n
• Einfachere Unterstützung von n8n
• Türöffner für die Bündelung anderer Produkte mit n8n in der Zukunft, wenn nötig, z. B. eine Vektordatenbank oder Redis.

Was wir gerne wissen möchten

Wir sind uns bewusst, dass es Situationen geben kann, in denen Docker schwierig zu nutzen ist. n8n wird auf alle möglichen Arten eingesetzt, und von einigen sind wir uns wahrscheinlich gar nicht bewusst. Deshalb möchten wir von euch allen zu diesem Thema hören – egal ob ihr derzeit npm oder Docker nutzt – bitte füll die Umfrage unten aus!

Link zur Umfrage

[BramKn]

Ich unterstütze das. Es ist lange her, seit ich eine npm-Installation von n8n genutzt habe, außer beim Entwickeln von Nodes.
Npm für n8n-Installationen führt immer irgendwann zu Problemen. Docker ist auch sicherer.
Wenn Clients wollen, dass wir ihre Instanz verwalten, drängen wir sie immer zu Docker, wenn sie npm nutzen. Das macht alles einfacher zu handhaben.

[achamm]

Ich stimme Bram zu, Docker ist viel leichter einzurichten und es ist schneller und hat Container, sodass es helfen kann, Sachen sicherer zu halten.

[Rene_Lutz]

Ich unterstütze die Richtung. Ich betreibe n8n selbst in Docker und habe vorher kurz mit npm experimentiert. Der Unterschied in der Stabilität und Wartbarkeit ist deutlich.
Was mich an der Entscheidung überzeugt: Der eingebettete KI-Assistent braucht eine Sandbox, und eine Sandbox braucht Docker. Das ist keine willkürliche Abhängigkeit sondern eine technisch begründete. Wer n8n ernsthaft einsetzt, hat Docker ohnehin meist schon laufen.
Der einzige Punkt der mich nachdenklich macht: Es gibt Nutzer die n8n auf sehr schlanken Umgebungen betreiben, zum Beispiel kleinen VPS ohne viel RAM, wo Docker spürbar mehr Ressourcen kostet als eine nackte npm-Installation. Für die wäre eine klare Migrationshilfe und idealerweise ein optimiertes Docker-Image wichtig.
Alles in allem: Weniger Varianten bedeutet weniger Bugs und schnellere Entwicklung. Das kommt der ganzen Community zugute.

[Parintele_Damaskin]

@sirdavidoff

Wenn du upgraden möchtest, musst du sicherstellen, dass Docker installiert ist, und stattdessen damit bereitstellen. Du könntest deine Installation immer noch im selben Verzeichnis behalten und dieses Verzeichnis in Docker mounten. Wir würden dir Anleitung geben, wie du das machst.

Naja, es ist Zeit, das Docker-Kaninchenloch mit CLI- und Desktop-Tutorials zu betreten.
Wenn ein Zauberer eine vollständige Dockerfile mit Queue, Workers, Task Runners, PostgreSQL, Redis-Beispiel teilen könnte… könnten wir sicherlich verhindern, dass npm-Liebhaber das in Zukunft wieder tun

P.S. einige lieben npm… einige lieben Docker… aber noch wichtiger ist, dass JEDER N8N liebt!!!

[Haian_Abou-Karam]

Ich stimme zu: Docker scheint hier der sauberere und wartbarere Weg zu sein, besonders für die KI-Assistent-Sandbox und langfristige Stabilität.

[kjooleng]

Das Upgrade von npm war ein Albtraum. Es gab viele Dependency-Probleme.
Docker ist einfacher, obwohl es mit einigen Overheads kommt. Verwaltbarkeit ist der Schlüssel.

+1 für Docker

[nguyenthieutoan]

Ich unterstütze diese Richtung. Aus meiner Erfahrung mit dem Betrieb von n8n auf VPS-Instanzen für mehrere Client-Umgebungen ist Docker über verschiedene n8n-Versionen hinweg deutlich vorhersehbarer als npm gewesen – besonders seitdem die AI Sandbox separate Prozessisolation erfordert.

Eine konkrete Anfrage, die ich hinzufügen würde: Eine minimale Single-Container-Compose-Datei, optimiert für kleine VPS (1-2 vCPU, 1-2 GB RAM), mit klarer Dokumentation darüber, welche Services deaktiviert werden können, um den Overhead zu reduzieren. Viele Self-Hosted-Nutzer betreiben n8n auf günstigen VPS, bei denen der Docker-Daemon selbst Speicherdruck erzeugt. Daher würde eine Anleitung zum minimalen Docker-Setup viel reibungsloser bei diesen Migrationen verlaufen.

[kevindo]

Ich führe Docker auf einem Ubuntu-VPS über MobaXterm aus. Diese Methode ist etwas technisch, aber für jeden, der sie schon mal verwendet hat, wird sie langfristig wahrscheinlich bevorzugt.
Docker Compose + Cloudflare Tunnel ist ein essentielles Setup für Nutzer – relativ einfach zu sichern, zu warten und sogar Daten zu migrieren.
Die Anforderung einer Sandbox-Umgebung für den KI-Assistenten ist einfach ein zusätzlicher Vorteil.

Aber muss die aktuelle Docker-Compose-Konfiguration irgendwelche Änderungen erfahren, wenn der Assistent gestartet wird? Oder ist es einfach ein zusätzlicher Container, der sich in das System einklinkt und darin ausgeführt wird?

[sirdavidoff]

@kevindo

Braucht das aktuelle Docker-Compose-Setup dennoch Änderungen, wenn der Assistent gestartet wird? Oder ist es einfach nur ein zusätzlicher Container, der sich in das gleiche System einstöpselt und dort läuft?

Sollte einfach nur ein zusätzlicher Container sein, ja

[Pier-Andre_Maynard]

Danke für die Transparenz zu diesem Thema. Ich stimme dir zu, dass es Vorteile gibt, zu Docker zu wechseln, aber es gibt auch ein paar technische Herausforderungen, einschließlich des Zugriffs auf lokale Dateien und das Ermöglichen von Kommandooperationen wie das Erstellen von Ordnern und Dateien. Das funktioniert heute mit mehreren Anpassungen und wird mit Docker noch komplexer.

Ein weiterer Punkt, der die Sache komplizieren könnte, ist die Docker-Lizenzierung selbst und was das für einige Nutzer bedeutet.

[Mounir_Benchellal]

Sehr gute Idee, außerdem ist der Name des npm-Hackings gewachsen, daher kann es die Daten eines beim Arbeiten in n8n beschädigen. Und um n8n in Docker zu installieren, braucht man technische Kenntnisse, aber man kann es lernen. Ich selbst hatte Probleme beim Installieren von n8n auf Docker Desktop, aber ich habe es Schritt für Schritt gelöst, indem ich auf YouTube gesucht und den chinesischen KI-Assistenten Deepseek befragt habe.

[tamy.santos]

unterstützt, Fragebogen ausgefüllt

[hsteph]

Glücklicherweise macht Coolify Docker benutzerfreundlicher. Dateizugriff bleibt etwas, das nicht leicht zu handhaben ist.

[nguyenthieutoan]

Selbstgehosted n8n für eine SaaS-Plattform mit mehreren Mandanten betreiben – vollständige Docker-First-Unterstützung. Bei der Multi-Worker-, Queue-Mode-Setup funktioniert alles zuverlässiger, wenn die n8n-Version und die Laufzeitumgebung auf den Containern für Main, Worker und Webhooks einheitlich sind. npm-basierte Installationen führen zu Drift auf der Host-OS-Ebene und verursachen subtile Unterschiede zwischen Umgebungen, die schwer zu debuggen sind. Die Sandboxing-Anforderung für den KI-Assistenten ist einfach der natürliche Endpunkt einer Richtung, die ohnehin bereits die richtige Entscheidung für Production-Deployments war.

[AvdA]

Das ist enttäuschende Nachricht - ich bin (noch kein Experte, aber ich habe versucht, Docker zu verwenden, und es hat meinen Computer zum Stillstand gebracht (Windows 16GB RAM mit lokal installiertem n8n). Als ich Docker deinstallierte und zur Verwendung von NPM zurückkehrte, konnte ich mich endlich auf echte Arbeit mit n8n konzentrieren, statt Zeit in Ressourcen-Kaninchenlöcher zu versenken. Ja, ich könnte meinen Computer aufrüsten, aber einige meiner Kunden haben einfachere Setups und ich muss manchmal damit arbeiten, was sie haben.
Aus meiner (zugegebenermaßen begrenzten) Perspektive scheint Docker bei einfachen Situationen eine unnötige Schicht aus Komplexität und Overhead hinzuzufügen. Wenn Docker aus technischen Gründen verfolgt werden muss, muss es dann so ressourcenhungrig sein?

[Axel_H]

Meiner Meinung nach können auch Nicht-Administratoren Docker installieren, und dank Tools wie Portainer ist es auch einfach zu verwalten. Das macht es für Anfänger (wie mich), die keine Cloud-Lösung möchten, leichter, den Einstieg zu finden.

Viele Optionen zu haben führt oft dazu, dass viele Menschen bei einer Entscheidung in einem Dilemma stecken. Manchmal ist es gut, wenn die Entscheidung für einen getroffen wird (ich beziehe mich hier auf Nutzer, die einfach nur eine Installation ausprobieren möchten).

Ich freue mich auf die Idee eines KI-Assistenten, und ich bin sicher, dass er n8n zu großen Fortschritten verhelfen wird.

Umfrage fertig? Erledigt

[medzin]

Ich bin einverstanden mit der Docker-only-Ausrichtung für die meisten Nutzer, und ein schlankes, gehärtetes Image ohne root-Standardbenutzer macht Sinn. Aber es hat zwei Eigenschaften, die es schwierig machen, es auf NAS-/selbst gehosteten Hosts (Unraid, Synology, …) gut zum Laufen zu bringen, und nur Docker zu unterstützen, macht diese von “einfach npm verwenden” zu harten Blockern:

1. Keine Host-UID/GID-Zuordnung. Das Image wird als ein fester node-Benutzer (UID 1000) ausgeführt, sodass bind-mounted Shares am Host mit der falschen UID/GID enden. Die etablierte Lösung (LinuxServer.io-Images und ähnliche) ist, als root zu starten, das erste Setup durchzuführen und dann auf einen Benutzer zu wechseln, der von den vom Host bereitgestellten PUID/PGID neu zugeordnet wird – so dass der Container die Share-Berechtigungen nie beschädigt.

2. Kein Paketmanager (apk ist entfernt). Einige NAS-Integrationen benötigen root + einen Paketmanager beim ersten Start – z.B. nutzt Unroids Tailscale-Integration einen Hook, der Tailscale beim Container-Start installiert und konfiguriert, was unmöglich wird, sobald apk/apt entfernt ist.

Wichtig ist, dass (1) nicht einfach nur ein Env-Flag für das aktuelle Image sein kann: UID-Remapping (chown von gemounteten Daten, usermod, Wechsel via su-exec/gosu) erfordert grundsätzlich, dass der Container als root startet. Das ist eine bewusste Änderung der Haltung vom gehärteten non-root-Standard – und genau deshalb denke ich, dass das in ein separates Image gehört, statt den Standard zu schwächen.

Also: würde das Team ein offiziell gepflegtes Self-Hosted-/NAS-Variant in Betracht ziehen – z.B. n8nio/n8n:<version>-nas – das als root startet, zu Host-PUID/PGID neu zuordnet, Privilegien abbaut und einen Paketmanager für First-Run-Hooks verfügbar hält? Der gehärtete Standard bleibt für alle anderen genau wie er ist.