n8n auf Proxmox: LXC oder VM richtig einrichten

Wer n8n selbst hosten will und bereits eine Proxmox-VE-Umgebung betreibt, steht vor der Frage, ob die Workflow-Automatisierung in einem LXC-Container oder in einer vollständigen virtuellen Maschine laufen soll. Für die meisten kleinen und mittleren Betriebe ist ein unprivilegierter LXC-Container mit aktivierter Nesting- und Keyctl-Funktion der pragmatischste Weg, weil er deutlich weniger Ressourcen bindet als eine VM und n8n innerhalb eines Docker-Containers laufen lassen kann. Wer maximale Isolation ohne Kompromisse braucht, sollte dagegen zur VM greifen. Stand: Juli 2026.

LXC oder VM: die Grundsatzentscheidung

n8n selbst stellt keine Proxmox-spezifischen Anforderungen, die Entscheidung fällt allein auf Ebene der Virtualisierungstechnik. Ein LXC-Container teilt sich den Kernel mit dem Proxmox-Host, startet sehr schnell und benötigt spürbar weniger Arbeitsspeicher als eine vergleichbare VM. Der Nachteil: Zwei Ebenen von Containern, LXC und Docker, teilen sich denselben Kernel, ein Kernel-Update auf dem Host kann im Zweifel beide Ebenen gleichzeitig betreffen. Eine VM kapselt n8n und den darin laufenden Docker-Daemon vollständig vom Host ab, kostet dafür aber mehr Arbeitsspeicher und Rechenleistung für einen eigenen Kernel. Für einen einzelnen n8n-Server in einem kleinen Betrieb ist der Ressourcenunterschied in der Praxis meist entscheidender als die theoretische Isolationsfrage.

Docker im LXC-Container: Nesting und Keyctl richtig setzen

Damit ein Docker-Daemon innerhalb eines LXC-Containers überhaupt arbeiten kann, muss der Container mit zusätzlichen Kernel-Schnittstellen ausgestattet werden. In der Proxmox-Dokumentation zu den Container-Optionen wird die Nesting-Funktion so beschrieben: "Allow nesting. Best used with unprivileged containers with additional id mapping. Note that this will expose procfs and sysfs contents of the host to the guest." Ohne dieses Flag scheitert der Docker-Daemon im Container regelmäßig beim Start. Zusätzlich braucht Docker in einem unprivilegierten Container die Keyctl-Option, die Proxmox so dokumentiert: "For unprivileged containers only: Allow the use of the keyctl() system call. This is required to use docker inside a container." Wichtig dabei: Wer Keyctl für Docker aktiviert, kann laut Proxmox-Dokumentation in derselben Konfiguration nicht gleichzeitig systemd-networkd nutzen, da beide Funktionen dieselbe Systemcall-Behandlung beanspruchen. Beide Optionen lassen sich in der Container-Konfiguration unter "Features" setzen. Ein privilegierter Container ist für den produktiven Einsatz nicht empfehlenswert, weil Proxmox neue Escape-Exploits aus privilegierten Containern ausdrücklich nicht mit derselben Priorität behandelt wie bei unprivilegierten Containern.

n8n per Docker installieren

Ist der LXC-Container vorbereitet, folgt die eigentliche n8n-Installation den gleichen Schritten wie auf jedem anderen Docker-Host. Laut der offiziellen n8n-Docker-Dokumentation wird zunächst ein Docker-Volume angelegt und n8n mit Port-Mapping auf 5678, den Zeitzonen-Variablen TZ und GENERIC_TIMEZONE sowie einem gemounteten Datenverzeichnis gestartet. Dieses Verzeichnis unter /home/node/.n8n enthält laut Dokumentation "encryption keys, instance logs, and source control feature assets" und bei der Standardkonfiguration zusätzlich die SQLite-Datenbank mit allen Workflows und Zugangsdaten. Wer stattdessen eine externe PostgreSQL-Datenbank anbinden will, ergänzt die passenden Umgebungsvariablen für Host, Port, Datenbankname und Zugangsdaten, das Datenverzeichnis bleibt laut n8n aber auch dann relevant, weil dort weiterhin wichtige Daten liegen. n8n weist an gleicher Stelle ausdrücklich darauf hin, dass Self-Hosting technisches Wissen in Server-Betrieb, Ressourcen-Management und Sicherheit voraussetzt und für erfahrene Nutzer gedacht ist. Wer diesen Aufbau nicht selbst betreuen möchte, findet bei NordFlux Unterstützung bei der n8n-Einrichtung und -Betreuung.

Backup: Proxmox-Snapshots ergänzend zum n8n-eigenen Backup

Ein LXC-Container lässt sich über die Proxmox-eigene Backup-Funktion sichern, die für Container laut Proxmox-Backup-Dokumentation wahlweise im Stop-, Suspend- oder Snapshot-Modus arbeitet. Im Snapshot-Modus wird der Container kurz angehalten, ein temporärer Storage-Snapshot erstellt und der Inhalt anschließend als Archiv gesichert, bevor der Snapshot wieder gelöscht wird. Das sichert zuverlässig den kompletten Container-Zustand inklusive Docker-Daemon und n8n-Datenverzeichnis, ersetzt aber kein anwendungsseitiges Backup. Wer gezielt nur Workflows und Zugangsdaten sichern will, sollte zusätzlich das n8n-eigene Datenverzeichnis regelmäßig exportieren, weil ein Proxmox-Snapshot immer den gesamten Container sichert und im Ernstfall länger dauert als das gezielte Zurückspielen einzelner Workflows. In der Praxis empfiehlt sich eine Kombination: geplante Proxmox-Backups für die vollständige Wiederherstellung des Servers und ein zusätzlicher, häufigerer Export der n8n-Workflows für den schnellen Einzelfall.

Häufige Fragen zu n8n auf Proxmox

Brauche ich zwingend Nesting und Keyctl, wenn ich Docker in einem LXC-Container nutzen will?

Ja, für Docker in einem unprivilegierten LXC-Container sind laut Proxmox-Dokumentation beide Optionen notwendig, sonst startet der Docker-Daemon nicht zuverlässig oder einzelne Funktionen schlagen fehl.

Ist ein privilegierter Container die einfachere Lösung?

Technisch oft ja, sicherheitstechnisch nein. Proxmox behandelt neue Escape-Exploits aus privilegierten Containern nicht mit derselben Priorität wie bei unprivilegierten Containern. Für einen produktiv genutzten n8n-Server mit gespeicherten Zugangsdaten ist das ein Risiko, das die meisten Betriebe nicht eingehen sollten.

Reicht ein Proxmox-Snapshot als einziges Backup für n8n?

Ein Snapshot sichert den gesamten Container zuverlässig, ist aber grobkörnig und für die Wiederherstellung einzelner Workflows unpraktisch. Sinnvoller ist die Kombination aus regelmäßigem Proxmox-Backup und einem zusätzlichen, gezielten Export der n8n-Workflows.

Läuft n8n in einer VM stabiler als im LXC-Container?

Nicht grundsätzlich stabiler, aber isolierter. Eine VM kapselt den Docker-Daemon vollständig vom Host-Kernel ab, das kostet Ressourcen, reduziert aber das Risiko, dass ein Kernel-Update auf dem Proxmox-Host beide Container-Ebenen gleichzeitig betrifft.