n8n auf Proxmox: LXC oder VM richtig einrichten

n8n läuft auf Proxmox VE in beiden Varianten. Für die meisten kleinen und mittleren Betriebe ist ein unprivilegierter LXC-Container mit den Features nesting und keyctl der pragmatische Weg. Eine virtuelle Maschine ist die richtige Wahl, wenn Sie maximale Isolation brauchen.

Dieser Artikel zeigt die Entscheidungskriterien, die nötigen Container-Optionen, die Installation per Docker und eine tragfähige Backup-Strategie.

Wann ist LXC und wann eine VM die richtige Wahl?

Nehmen Sie einen LXC-Container, wenn Arbeitsspeicher knapp ist und n8n der einzige Dienst darin bleibt. Nehmen Sie eine VM, wenn n8n vom Kernel des Proxmox-Hosts unabhängig sein soll.

n8n selbst stellt keine Proxmox-spezifischen Anforderungen. Die Entscheidung fällt allein auf Ebene der Virtualisierungstechnik.

Kriterium | LXC-Container | Virtuelle Maschine

Kriterium: Kernel · LXC-Container: geteilt mit dem Proxmox-Host · Virtuelle Maschine: eigener Kernel im Gast

Kriterium: Arbeitsspeicher · LXC-Container: nur für die Prozesse · Virtuelle Maschine: zusätzlich für den Gast-Kernel

Kriterium: Startzeit · LXC-Container: wenige Sekunden · Virtuelle Maschine: vollständiger Boot-Vorgang

Kriterium: Isolation · LXC-Container: Namespaces, cgroups, AppArmor · Virtuelle Maschine: Hardware-Virtualisierung

Kriterium: Docker im Gast · LXC-Container: nur mit nesting und keyctl · Virtuelle Maschine: ohne Zusatzoptionen

Kriterium: Migration im laufenden Betrieb · LXC-Container: nicht möglich, nur mit Neustart · Virtuelle Maschine: Live-Migration möglich

Kriterium: Snapshot inklusive Arbeitsspeicher · LXC-Container: nein · Virtuelle Maschine: ja

Die Proxmox-Dokumentation zu Containern empfiehlt für Anwendungsfälle mit maximaler Isolation und Live-Migration ausdrücklich, Container in einer QEMU-VM zu verschachteln. Für einen einzelnen n8n-Server in einem kleinen Betrieb wiegt der Ressourcenunterschied in der Praxis meist schwerer.

Welche Container-Optionen braucht Docker im LXC?

Docker braucht in einem unprivilegierten LXC-Container die beiden Features nesting=1 und keyctl=1. Fehlen sie, startet der Docker-Daemon nicht zuverlässig.

Die Proxmox-Dokumentation zu den Container-Optionen beschreibt nesting so: "Allow nesting. Best used with unprivileged containers with additional id mapping." Zu keyctl heißt es dort: "For unprivileged containers only: Allow the use of the keyctl() system call. This is required to use docker inside a container."

Der folgende Befehl legt einen passenden Container an. Er läuft auf der Shell des Proxmox-Hosts.

1pct create 110 local:vztmpl/debian-12-standard_12.7-1_amd64.tar.zst \
2  --hostname n8n \
3  --unprivileged 1 \
4  --cores 2 \
5  --memory 4096 \
6  --swap 1024 \
7  --rootfs local-lvm:16 \
8  --net0 name=eth0,bridge=vmbr0,ip=dhcp \
9  --features nesting=1,keyctl=1 \
10  --onboot 1
11
12pct start 110
Copy

Bei einem bestehenden Container ergänzen Sie die Features nachträglich. Der Container muss dafür neu starten.

1pct set 110 --features nesting=1,keyctl=1
2pct reboot 110
Copy

In der Konfigurationsdatei unter /etc/pve/lxc/110.conf steht danach diese Zeile:

1features: keyctl=1,nesting=1
Copy

Ein Detail wird oft übersehen. Proxmox weist darauf hin, dass keyctl im Kern ein Behelf für systemd-networkd ist: "Essentially, you can choose between running systemd-networkd or docker." Nutzen Sie im Container also die klassische Netzwerkkonfiguration.

Ein privilegierter Container umgeht diese Punkte, ist aber keine gute Idee. Laut Proxmox behandelt das LXC-Team neue Escape-Exploits aus privilegierten Containern nicht als CVE-würdige Sicherheitslücken.

Wie installieren Sie n8n im vorbereiteten Container?

Nach dem Start installieren Sie Docker im Container und starten n8n mit einem benannten Volume auf /home/node/.n8n. Die Schritte entsprechen denen auf jedem anderen Docker-Host.

Die offizielle n8n-Docker-Dokumentation zeigt den Start mit docker run und den Variablen TZ und GENERIC_TIMEZONE. Der folgende Befehl ergänzt das um einen Neustart-Modus und eine feste Version.

1docker volume create n8n_data
2
3docker run -d --restart unless-stopped \
4  --name n8n \
5  -p 5678:5678 \
6  -e GENERIC_TIMEZONE="Europe/Berlin" \
7  -e TZ="Europe/Berlin" \
8  -e N8N_ENFORCE_SETTINGS_FILE_PERMISSIONS=true \
9  -e N8N_RUNNERS_ENABLED=true \
10  -v n8n_data:/home/node/.n8n \
11  n8nio/n8n:1.81.0
Copy

Das Beispiel der n8n-Dokumentation nutzt -it --rm für einen Testlauf. Für den Dauerbetrieb ist -d --restart unless-stopped die passende Variante. Der feste Versions-Tag verhindert, dass ein docker pull unbemerkt eine neue Hauptversion zieht.

Das Verzeichnis /home/node/.n8n enthält laut n8n "encryption keys, instance logs, and source control feature assets" und bei Standardkonfiguration zusätzlich die SQLite-Datenbank. Ohne dieses Volume sind Workflows und Zugangsdaten nach dem nächsten Neuaufbau verloren.

n8n weist an gleicher Stelle darauf hin, dass Self-Hosting Wissen in Server-Betrieb, Ressourcen-Management und Absicherung voraussetzt. Wer diesen Aufbau nicht selbst betreuen möchte, findet bei NordFlux Unterstützung bei der n8n-Einrichtung und -Betreuung.

Wie statten Sie den Container aus?

Die Ausstattung richtet sich nach der Zahl paralleler Ausführungen und der Datenmenge je Ausführung. Die folgende Tabelle nennt die Proxmox-Felder, die Sie dafür setzen, und sinnvolle Startwerte für eine einzelne Instanz mit SQLite.

Proxmox-Feld | Wert | Begründung

Proxmox-Feld: Cores · Wert: 2 · Begründung: ein Kern für n8n, einer für Docker und System

Proxmox-Feld: Memory · Wert: 4096 MB · Begründung: Node.js hält Ausführungsdaten im Arbeitsspeicher

Proxmox-Feld: Swap · Wert: 1024 MB · Begründung: Puffer für einzelne große Ausführungen

Proxmox-Feld: Rootfs · Wert: 16 GB · Begründung: Docker-Images, Logs und SQLite-Datenbank

Proxmox-Feld: Features · Wert: nesting=1,keyctl=1 · Begründung: Voraussetzung für Docker

Proxmox-Feld: Start at boot · Wert: aktiviert · Begründung: n8n soll nach einem Host-Neustart laufen

Proxmox-Feld: Unprivileged · Wert: aktiviert · Begründung: Standard und sicherheitstechnisch geboten

Workflows mit großen Binärdateien verschieben die Grenzen deutlich nach oben. Beobachten Sie die Auslastung im Proxmox-Summary, bevor Sie die Werte festschreiben.

Wie sichern Sie n8n auf Proxmox richtig?

Kombinieren Sie ein Proxmox-Backup des ganzen Containers mit einem gezielten Export der Workflows. Beides deckt unterschiedliche Notfälle ab.

Die Proxmox-Backup-Dokumentation kennt für Container drei Modi.

Modus | Ablauf | Ausfallzeit

Modus: stop · Ablauf: Container wird für die Dauer des Backups gestoppt · Ausfallzeit: am längsten

Modus: suspend · Ablauf: rsync, dann kurzes Anhalten, dann zweiter rsync · Ausfallzeit: gering, braucht Zwischenspeicher

Modus: snapshot · Ablauf: kurzes Anhalten, Storage-Snapshot, Archivierung · Ausfallzeit: am kürzesten

Der Snapshot-Modus setzt voraus, dass alle gesicherten Volumes auf einem Storage mit Snapshot-Unterstützung liegen. Ein geplantes Backup lässt sich auch direkt anstoßen:

1vzdump 110 --storage backup-nfs --mode snapshot --compress zstd
Copy

Ein Proxmox-Backup stellt den kompletten Server wieder her, ist für einen einzelnen kaputten Workflow aber grobkörnig. Ergänzen Sie deshalb den Export über die n8n-Kommandozeile, dokumentiert unter Use the command line.

1docker exec -u node n8n n8n export:workflow --backup --output=/home/node/.n8n/backups/latest/
Copy

Setzen Sie zusätzlich N8N_ENCRYPTION_KEY fest. Sonst erzeugt n8n beim ersten Start einen Zufallsschlüssel, und die Zugangsdaten aus einem Export sind auf einer neuen Instanz nicht mehr lesbar.

Typische Fehler und Ursachen

Fünf Fehlerbilder treten beim Betrieb von n8n auf Proxmox besonders häufig auf.

Der Docker-Daemon startet im Container nicht.

Ursache: Die Features nesting und keyctl fehlen, der Container darf den Systemaufruf keyctl() nicht nutzen. Lösung: pct set <ID> --features nesting=1,keyctl=1 setzen und den Container neu starten. Quelle: Proxmox Container Options.

Nach dem Aktivieren von keyctl bricht die Netzwerkkonfiguration weg.

Ursache: systemd-networkd und Docker beanspruchen dieselbe Behandlung des Systemaufrufs, Proxmox nennt das eine Entweder-oder-Entscheidung. Lösung: im Container auf die klassische Netzwerkkonfiguration wechseln und systemd-networkd deaktivieren. Quelle: Proxmox Container Options.

Nach dem Wiederherstellen sind alle Zugangsdaten unbrauchbar.

Ursache: Das Volume auf /home/node/.n8n fehlte, n8n hat beim Start einen neuen Verschlüsselungsschlüssel erzeugt. Lösung: Volume dauerhaft mounten und N8N_ENCRYPTION_KEY fest vorgeben. Quelle: Umgebungsvariablen für das Deployment.

Zeitplan-Nodes feuern zur falschen Uhrzeit.

Ursache: Nur eine der beiden Zeitzonen-Variablen ist gesetzt, der Container läuft sonst auf UTC. Lösung: TZ und GENERIC_TIMEZONE auf denselben Wert setzen, etwa Europe/Berlin. Quelle: Installation mit Docker.

Das Backup im Snapshot-Modus schlägt fehl.

Ursache: Mindestens ein Volume des Containers liegt auf einem Storage ohne Snapshot-Unterstützung. Lösung: auf suspend wechseln oder das betroffene Volume per backup=no ausnehmen. Quelle: Proxmox Backup and Restore.

Häufige Fragen zu n8n auf Proxmox

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

Ja. Laut Proxmox-Dokumentation ist keyctl für Docker in unprivilegierten Containern ausdrücklich erforderlich, nesting erlaubt die zweite Container-Ebene. Ohne beide startet der Docker-Daemon nicht zuverlässig.

Ist ein privilegierter Container die einfachere Lösung?

Technisch oft ja, sicherheitstechnisch nein. Das LXC-Team behandelt neue Escape-Exploits aus privilegierten Containern nicht als CVE-würdige Sicherheitslücken. Für einen n8n-Server mit gespeicherten Zugangsdaten ist das ein unnötiges Risiko.

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

Er sichert den Container zuverlässig, ist für die Wiederherstellung einzelner Workflows aber zu grobkörnig. Sinnvoll ist die Kombination aus geplantem Proxmox-Backup und regelmäßigem Export über n8n export:workflow.

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

Nicht stabiler, aber isolierter. Eine VM bringt einen eigenen Kernel mit und erlaubt Live-Migration. Das kostet Arbeitsspeicher, entkoppelt n8n aber von Kernel-Updates auf dem Proxmox-Host.