Docker in Proxmox: VM oder LXC-Container?

Kurz gesagt: Lass Docker in einer schlanken Debian-VM laufen — das ist der robuste, offiziell empfohlene Standardweg mit sauberem Isolationsmodell, bei dem Proxmox-Updates nie in deine Container-Welt hineinfunken. Docker im LXC spart zwar spürbar Ressourcen, ist aber von Proxmox ausdrücklich nicht empfohlen: Es braucht Nesting-Gefrickel und kann nach einem Host-Update brechen. Der LXC-Weg lohnt sich nur, wenn jedes GB RAM zählt und du bewusst bastelst.

Kaum eine Frage kommt im Proxmox-Homelab so zuverlässig auf wie diese: Der frisch installierte Hypervisor läuft, jetzt sollen Docker-Dienste her — aber wohin damit? Beide Wege funktionieren erstmal, und genau das macht die Entscheidung tückisch. Dieser Guide erklärt die Architektur dahinter, zeigt beide Wege konkret und sagt klar, wann welcher passt.

Warum stellt sich die Frage überhaupt? #

Weil Docker selbst eine Container-Technologie ist — und Proxmox mit LXC schon eine mitbringt. Ein LXC-Container teilt sich den Kernel mit dem Proxmox-Host: leichtgewichtig, startet in Sekunden, kaum Overhead. Eine VM bringt dagegen einen kompletten eigenen Kernel mit und ist per Hardware-Virtualisierung (KVM) sauber vom Host getrennt.

Docker im LXC bedeutet also: Container-Runtime in einer Container-Runtime, beide auf demselben Host-Kernel. Das geht technisch — Docker braucht dafür aber Kernel-Features (Namespaces, cgroups, Overlay-Dateisysteme, Security-Profile), die durch die LXC-Schicht hindurchgereicht werden müssen. Genau an dieser Stelle entsteht die Reibung. In der VM existiert das Problem nicht: Docker sieht dort einen ganz normalen eigenen Linux-Kernel und verhält sich exakt wie auf jedem Bare-Metal-Server.

Die Proxmox-Dokumentation ist bei dem Thema eindeutig: Wenn du Docker (oder andere anwendungsbezogene Container) betreiben willst, empfiehlt Proxmox ausdrücklich, das in einer VM zu tun — nicht im LXC.

Der VM-Weg: Debian + Docker (die Empfehlung) #

So sieht der Standardweg konkret aus — eine schlanke Debian-VM als Docker-Host:

1. Debian-netinst-ISO herunterladen und in Proxmox hochladen (Node → local → ISO Images → Upload)
2. VM anlegen: Als Richtwerte reichen 2 CPU-Kerne, 2–4 GB RAM und 20–32 GB Disk für den Einstieg locker — alles später über die Weboberfläche anpassbar. Disk als VirtIO/SCSI, Netzwerk als VirtIO, den QEMU Guest Agent aktivieren.
3. Debian minimal installieren: Bei der Paketauswahl alles abwählen außer „SSH server“ und „standard system utilities“ — kein Desktop.
4. Docker installieren, am saubersten über das offizielle Docker-Repository (die aktuelle Anleitung steht in der Docker-Doku). Danach:

apt install qemu-guest-agent -y
systemctl enable --now qemu-guest-agent
docker run hello-world

Ab hier arbeitest du wie auf jedem Docker-Host: ein Verzeichnis pro Stack, eine compose.yaml, docker compose up -d. Die VM ist dein einziger „Haustier“-Server — alles darin ist wegwerfbare, per Compose-Datei reproduzierbare Ware.

Der entscheidende Vorteil zeigt sich im Betrieb: Updates sind entkoppelt. Du kannst den Proxmox-Host aktualisieren und neu starten, ohne dass sich in der Docker-Welt irgendetwas ändert — und umgekehrt. Genau diese Sorglosigkeit ist es, die den VM-Weg zum Standard macht.

Der LXC-Weg: möglich, aber mit Sternchen #

Docker läuft auch im LXC — mit den richtigen Schaltern. In den Optionen des Containers (am einfachsten ein unprivilegierter Container) müssen unter Options → Features gesetzt sein:

nesting=1
keyctl=1

Ohne nesting startet der Docker-Daemon gar nicht erst; keyctl braucht es in unprivilegierten Containern, damit systemd und Docker nicht über Kernel-Keyring-Aufrufe stolpern. Je nach Setup kommen weitere Handgriffe dazu — etwa Anpassungen am AppArmor-Profil oder Umwege beim Storage-Treiber, wenn Docker auf dem Container-Dateisystem kein Overlay nutzen kann und in den langsamen vfs-Treiber zurückfällt.

Und damit sind wir beim eigentlichen Problem. Es ist nicht, dass es nicht läuft — es läuft oft monatelang tadellos. Das Problem ist die Fragilität: Deine Docker-Installation hängt an Kernel- und AppArmor-Details des Hosts, die Proxmox bei Updates jederzeit ändern darf. Ein Kernel- oder AppArmor-Update auf dem Host kann eine bis dahin stabile Docker-im-LXC-Konstellation brechen — und weil die Kombination offiziell nicht empfohlen ist, bist du bei der Fehlersuche auf Forenwissen angewiesen. Dazu kommt das Sicherheitsmodell: Alle Docker-Container im LXC laufen letztlich auf dem Host-Kernel. Die harte Isolationsgrenze der VM fehlt.

Wofür der LXC-Weg trotzdem taugt: Bastel-Setups auf sehr schwacher Hardware, bei denen jedes GB RAM zählt, und Dienste, deren Ausfall dich nicht schmerzt — mit dem Wissen, dass nach einem Host-Update Nacharbeit anstehen kann.

Ressourcen-Overhead ehrlich eingeordnet #

Ja, die VM kostet mehr — aber weniger, als der Ruf vermuten lässt. Als grobe Richtwerte (keine Messwerte, die Realität hängt stark von deinem Setup ab):

• RAM: Die VM reserviert zugewiesenen Speicher fest und bringt Kernel plus eigenes Basissystem mit — rechne grob mit einigen hundert MB „Grundrauschen“, die ein LXC nicht hätte. Der LXC teilt sich RAM dynamisch mit dem Host und ist hier klar effizienter.
• CPU: Der KVM-Virtualisierungs-Overhead ist auf moderner Hardware für typische Homelab-Dienste vernachlässigbar.
• Disk: Die VM belegt zusätzlich ihr Basissystem — bei einem minimalen Debian ein einstelliger GB-Betrag.

Die ehrliche Einordnung: Auf einem Host mit 16 GB RAM oder mehr ist dieser Unterschied für einen Docker-Host irrelevant. Spürbar wird er erst auf sehr knapper Hardware — oder wenn du viele separate Umgebungen fährst. Beim Stromverbrauch macht der Unterschied im Leerlauf übrigens kaum etwas aus; was dein 24/7-Server insgesamt kostet, zeigt dir der Stromkosten-Rechner.

Backup: vzdump sichert den ganzen Host #

Ein oft übersehener Pluspunkt beider Wege: Das eingebaute Proxmox-Backup (vzdump, Datacenter → Backup) sichert die ganze VM bzw. den ganzen LXC als ein Image — inklusive aller Docker-Container, Volumes, Compose-Dateien und Konfigurationen darin. Ein Restore bringt den kompletten Docker-Host in einem Rutsch zurück; du musst Docker-Volumes nicht einzeln sichern.

Zwei Dinge dabei beachten: Erstens gehören die Daten deiner Container dafür auch wirklich in die VM/den LXC — Bind-Mounts auf externe Shares sichert vzdump nicht mit. Zweitens ersetzt ein VM-Backup keine anwendungsbewusste Sicherung für Datenbanken mit hoher Schreiblast; für typische Homelab-Dienste ist der Snapshot-Modus aber völlig ausreichend.

Entscheidungshilfe #

• Du willst einen Docker-Host, der einfach läuft: Debian-VM. Punkt. Das ist der offiziell empfohlene Weg, und du wirst nie darüber nachdenken müssen, ob das nächste Proxmox-Update deine Dienste zerlegt.
• Deine Hardware ist sehr knapp (unter ~8 GB RAM): Dann ist Docker im LXC mit nesting und keyctl vertretbar — als bewusste Bastel-Entscheidung, mit Backup und der Bereitschaft, nach Host-Updates nachzuarbeiten.
• Native Linux-Dienste ohne Docker: Dafür sind LXC-Container ohne Einschränkung großartig — die Faustregel „LXC für einzelne Linux-Dienste, VM für Docker“ aus dem Proxmox-Einsteiger-Guide gilt weiter.
• Du fragst dich, ob Proxmox überhaupt die richtige Plattform ist: Wenn dein Server primär NAS mit ein paar Docker-Diensten sein soll, lohnt der Blick auf den Vergleich Unraid vs. Proxmox vs. TrueNAS — dort ist Docker jeweils nativer integriert.

Am Ende ist es die alte Abwägung Robustheit gegen Effizienz — und im Homelab, wo niemand nachts für dich Bereitschaft schiebt, gewinnt Robustheit fast immer. Die Debian-VM mit Docker Compose ist unspektakulär, langweilig und genau deshalb richtig.