Proxmox LXC vs. VM vs. Docker in 2026: Was wofür nutzen [Entscheidungsleitfaden]

Alle paar Jahre kocht in der Proxmox-Welt dasselbe Streitthema wieder hoch. Jemand stellt eine ehrliche, praktische Frage: Warum nicht einfach Docker in einem LXC laufen lassen? Es funktioniert. Es ist schnell. Es braucht weniger Speicher. Und jede Menge Leute machen das seit Jahren ohne Probleme.

Und dann rollen die Antworten herein.

"Nicht unterstützt."

"Nutzen Sie einfach eine VM."

"Das bricht beim Upgrade."

"Container in Containern ist eine Einladung für Ärger."

Vorspulen ins Jahr 2026, und hier sind wir wieder – immer noch am Streiten, immer noch am Deployen, immer noch am stillen Brechen der "Regeln" in Homelabs und Edge-Servern überall. Selbst mit neueren Funktionen und einer etwas softeren offiziellen Haltung von Proxmox VE weigert sich die Docker-in-LXC-Debatte, sich zu beruhigen.

Das liegt nicht daran, dass Menschen stur sind. Es liegt daran, dass die Kompromisse real sind und die Anreize auf beiden Seiten nicht verschwunden sind.

Zwei Plattformen, ein Kernel, null Geduld füreinander

Im Kern der Debatte steckt eine einfache architektonische Spannung. Proxmox ist eine Virtualisierungsplattform. Docker ist auch eine Virtualisierungsplattform, nur auf einer anderen Ebene. Beide verlassen sich stark auf den Linux-Kernel, um ihre Arbeit zu erledigen.

Ein LXC-Container auf Proxmox teilt sich den Kernel mit dem Host. Docker-Container erwarten ebenfalls, direkt mit dem Host-Kernel zu sprechen. Wenn Sie Docker in einem LXC laufen lassen, stapeln Sie zwei Systeme, die beide davon ausgehen, dem Kernel am "nächsten" zu sein.

Meistens ist Linux flexibel genug, damit das funktioniert. Bis es das nicht mehr ist.

Kernel-Updates. Änderungen an AppArmor-Profilen. Verschiebungen bei der Cgroup-Version. Anpassungen an Dateisystemtreibern. Keins davon ist ein exotischer Sonderfall. Das sind normale Bestandteile davon, einen Host sicher und aktuell zu halten. Und wenn sich auf der Proxmox-Ebene etwas ändert, weiß Docker weder, dass es in LXC läuft, noch kümmert es das. Genauso testet Proxmox seine Updates nicht gegen Docker, das in Containern läuft, die es offiziell nicht unterstützt.

Aus dieser Lücke stammen die Horrorgeschichten.

"Aber ich betreibe Docker seit Jahren in LXC"

Das hören Sie oft. Und es stimmt meistens.

Viele Nutzer betreiben Docker seit fünf, sechs, sogar sieben Jahren in unprivilegierten LXCs. Manche haben mehrere große Proxmox-Releases am Stück durchgezogen, ohne einen einzigen Vorfall. Ihre Schlussfolgerung liegt auf der Hand: Das Risiko wird überschätzt.

Der Haken ist, dass dieser Erfolg ungleich verteilt ist. Wenn Ihre Workloads leicht sind, Ihr Storage-Layout einfach und Sie nicht auf Kernel-Sonderfälle angewiesen sind, kann sich Docker in LXC bombenfest anfühlen. Wenn Sie GPUs, fortgeschrittenes Networking oder Storage-Treiber ausreizen, die direkt an der Grenze zwischen Kernel und User Space sitzen, zeigen sich Risse.

Genau diese Unvorhersehbarkeit ist der Grund, warum Proxmox immer wieder denselben Rat wiederholt. Nicht weil es nie funktioniert, sondern weil es, wenn es scheitert, auf eine Weise scheitert, die sie nicht einfach unterstützen oder debuggen können.

Szenario eins: "Nutzen Sie einfach LXC, kein Docker"

Das am wenigsten umstrittene Setup ist auch das am wenigsten angesagte. Reine LXCs, traditionelle Pakete, systemd-Services, vielleicht mit Ansible zusammengeklebt.

Aus Proxmox' Sicht ist das der Happy Path. LXCs sind erstklassige Bürger. Sie sind getestet. Sie sind dokumentiert. Hier sollen Kernel-Updates funktionieren.

Der Nachteil ist offensichtlich, wenn Sie das letzte Jahrzehnt im Container-Land verbracht haben. Viele moderne Services werden nicht mehr wirklich als "Software" ausgeliefert. Sie werden als Docker-Images ausgeliefert. Kein apt-Repo. Keine saubere Installationsanleitung. Nur eine Compose-Datei und ein Stoßgebet.

Diese Stacks von Hand nachzubauen ist nicht unmöglich, aber es ist Arbeit. Und es ist andauernde Arbeit. Abhängigkeiten ändern sich. Dokumentation driftet auseinander. Plötzlich sieht Ihr "einfaches" LXC aus wie eine eigene Distribution, die Sie allein pflegen.

Szenario zwei: Docker in LXC

Das ist der umstrittene Mittelweg – und der Grund, warum die Debatte nicht sterben will.

Auf dem Papier bringt Docker-in-LXC nicht viel zusätzliche Isolation. Beide Ebenen nutzen dieselben Kernel-Funktionen: Namespaces, Cgroups, Capabilities. Sie sind nicht wirklich sicherer. Sie sind auch nicht nennenswert schneller. Was Sie tatsächlich tun, ist, die Abstraktion zu verdoppeln.

Pfade werden doppelt gemappt. Ports werden doppelt weitergeleitet. UID- und GID-Mappings werden zu einem kleinen Persönlichkeitstest.

Und trotzdem machen es die Leute weiter. Warum? Weil die Ergonomie unschlagbar ist. Docker Compose ist einfach. Dokumentation existiert. Backups sind simpel. Migration ist oft nur das Kopieren eines Verzeichnisses und das erneute Starten eines Stacks.

Das eigentliche Risiko ist nicht Performance oder Sicherheit. Es ist Kompatibilitätsdrift. Docker aktualisiert seine Laufzeitumgebung. Proxmox aktualisiert seinen Kernel oder seine LXC-Profile. Niemand koordiniert diese Änderungen über die Ebenen hinweg. Meistens explodiert nichts. Manchmal doch.

Wenn es bricht, dann meistens nach einem Upgrade. Und wenn es soweit ist, sind Sie auf sich allein gestellt.

Szenario drei: Docker in einer VM

Das ist die langweilige, sichere Antwort. Und in der Produktion gewinnt meist das Langweilige.

Eine VM bekommt ihren eigenen Kernel. Docker ist glücklich. Proxmox ist glücklich. Updates verursachen weit seltener seltsame Berechtigungsfehler oder Kernel-Feature-Konflikte. Live-Migration funktioniert. HA funktioniert. Support-Tickets ergeben Sinn.

Der Preis ist Overhead. Selbst eine schlanke VM braucht Speicher für ihren Kernel, ihr Init-System und ihre Leerlaufprozesse. Auf einem großen Server ist das Rauschen. Auf einer kleinen Box oder einem stromsparenden Homelab ist es der Unterschied zwischen "alles passt" und "Sie müssen Entscheidungen treffen".

GPU-Passthrough wird ebenfalls kniffliger. Eine VM neigt dazu, Hardware zu monopolisieren, sofern Sie sie nicht sorgfältig aufteilen, und nicht jeder will sich mit dieser Komplexität herumschlagen.

Trotzdem: Wenn Betriebszeit wichtiger ist als das letzte Watt herauszuquetschen, ist das der Weg, für den Proxmox eigentlich entworfen ist.

Warum Upgrades der eigentliche Bösewicht sind

Die häufigsten Bruchstellen sind nicht dramatisch. Es sind langweilige Details.

Eine Container-Laufzeitumgebung ändert, wie sie mit /proc umgeht.

Ein AppArmor-Profil wird leicht verschärft.

Ein Storage-Treiber kippt sein Standardverhalten.

Jede Änderung für sich ist vernünftig. Über mehrere Ebenen hinweg kombiniert, können sie verhindern, dass Container überhaupt starten.

Deshalb sagen Leute: "Docker in LXC bricht bei Upgrades." Das ist kein Aberglaube. Es ist die Anerkennung, dass Sie zwei sich schnell entwickelnde Systeme betreiben, die nicht gegeneinander getestet werden.

Wenn Sie Upgrades verzögern, gute Backups pflegen und gelegentliche Ausfallzeit akzeptieren, ist dieses Risiko vielleicht in Ordnung. Wenn Sie am ersten Tag eines neuen Release vorhersehbares Verhalten brauchen, ist es das wahrscheinlich nicht.

Der OCI-Joker

Neuere Versionen von Proxmox haben frühe Unterstützung dafür hinzugefügt, OCI-Images direkt auszuführen, ohne einen Docker-Daemon in einem LXC hochzufahren. Das ist eine subtile, aber wichtige Verschiebung.

Statt Laufzeitumgebungen zu verschachteln, behandelt Proxmox das Image als Eingabe und führt es mit seinem eigenen Container-Stack aus. Das entfernt eine ganze Reibungsebene. Kein Docker-Socket. Kein runc in LXC. Proxmox verwaltet den Container-Lebenszyklus einfach selbst.

Das ist vielversprechend. Es ist aber auch noch nicht fertig.

Es gibt noch kein ausgereiftes Äquivalent zu Docker Compose. Orchestrierung ist rudimentär. Upgrades sind vorsichtig. Im Moment fühlt es sich an wie ein Blick in eine Zukunft, in der diese Debatte sich endlich beruhigen könnte – aber noch nicht etwas, worauf jeder heute schon seine Infrastruktur verwetten sollte.

Warum das Streitthema immer wiederkehrt

Diese Debatte überlebt, weil es nicht um Richtig und Falsch geht. Es geht um Prioritäten.

Wenn Sie Effizienz über alles andere stellen, sind LXCs – mit oder ohne Docker – unglaublich überzeugend. Speicherteilung ist real. Startzeiten sind sofort. Der Ressourcenverbrauch fühlt sich ehrlich an.

Wenn Sie Stabilität und Support schätzen, gewinnen VMs von Haus aus. Die Isolation ist sauberer. Der Explosionsradius ist kleiner. Die Regeln sind klarer.

Und wenn Sie Bequemlichkeit schätzen, bleibt Docker schwer zu schlagen. Diese Bequemlichkeit verschwindet nicht nur, weil Ihnen jemand sagt, es sei "nicht unterstützt".

Also mischen und kombinieren die Leute weiter. Sie akzeptieren die Risiken, die ihnen am wenigsten wichtig sind, und ignorieren den Rest. Dann landet ein neues Proxmox-Release, etwas ändert sich, und das Gespräch beginnt von vorn.

2026 sind die Tools besser. Die Kernel sind schlauer. Die Warnungen sind klarer. Aber die Kompromisse sind immer noch da.

Deshalb weigert sich diese Debatte zu sterben. Nicht weil Menschen sich nicht einig werden können – sondern weil, je nachdem, wie Sie Ihre Systeme betreiben, alle ein kleines bisschen recht haben.