Proxmox vs. Docker: Was wo ausführen

Sie haben gerade eine Proxmox-Box aufgebaut oder eine geerbt, und jetzt möchten Sie darauf Docker-Workloads betreiben. Praktisch jedes Suchergebnis stellt das als Entweder-oder dar – Proxmox oder Docker – und dieser Rahmen ist falsch. Genau deshalb geben Leute entweder eine funktionierende Proxmox-Installation auf oder pressen Docker an die falsche Stelle.

TL;DR

Proxmox ist ein Type-1-Hypervisor – er virtualisiert Hardware und betreibt vollständige VMs sowie LXC-Systemcontainer auf Bare Metal.
Docker ist eine Laufzeitumgebung für Anwendungscontainer – es verpackt eine App samt Abhängigkeiten in einen portablen, wegwerfbaren Container.
Die beiden stehen nicht in Konkurrenz zueinander. In einem echten Homelab erschafft Proxmox die Maschine; Docker betreibt darin die Apps.
Die eigentliche Entscheidung lautet nicht „Proxmox oder Docker" – sondern VM oder LXC für Ihren Docker-Host.
Proxmox empfiehlt selbst, Docker in einer VM zu verschachteln statt in einem privilegierten LXC, sobald Isolation wichtig ist.

KEY-STAT: Proxmox VE 9.x läuft auf Debian 13 „Trixie" mit KVM für vollständige Virtualisierung und LXC für leichtgewichtige Systemcontainer — Basisebene, keine App-Laufzeitumgebung

Keine Konkurrenten – unterschiedliche Ebenen

Proxmox und Docker lösen zwei völlig unterschiedliche Probleme, und ein direkter Vergleich ergibt nur Sinn, wenn man akzeptiert, dass sie übereinander liegen, nicht nebeneinander.

Docker beschreibt sich in der eigenen Dokumentation als „eine offene Plattform zum Entwickeln, Versenden und Betreiben von Anwendungen", die Software „in einer lose isolierten Umgebung namens Container" verpackt – siehe die Docker-Übersichtsdokumentation. Das ist ein Anwendungs-Thema.

Proxmox hingegen beschäftigt sich mit Hardware. Es macht aus einem physischen Server viele isolierte virtuelle Maschinen und Container. Sie entscheiden sich so gut wie nie für das eine statt des anderen – Sie nutzen Proxmox, um die Maschine zu bauen, und entscheiden dann, was darauf läuft. Docker ist meist Teil dieser Antwort.

Was Proxmox eigentlich ist

Proxmox Virtual Environment ist ein Type-1-(Bare-Metal-)Hypervisor – es installiert sich direkt auf der Hardware, nicht innerhalb eines anderen Betriebssystems. Die aktuelle 9.x-Reihe basiert auf Debian 13 „Trixie" und nutzt KVM für vollständige virtuelle Maschinen sowie LXC für leichtgewichtige Systemcontainer, laut Proxmox' eigener Dokumentation.

Tipp

„Type-1-Hypervisor" ist das Detail, über das viele stolpern. Proxmox sitzt nicht auf Windows oder Ubuntu auf – es ist das Betriebssystem auf dem Blech, weshalb es CPU, RAM und Datenträger direkt zwischen VMs aufteilen kann.

Innerhalb von Proxmox gibt es zwei Bausteine: eine VM (eine vollständige virtuelle Maschine mit eigenem Kernel, die wie echte Hardware bootet) und einen LXC-Container (ein leichtgewichtiger „Systemcontainer", der sich den Kernel des Proxmox-Hosts teilt, sich ansonsten aber wie ein kleines vollständiges Betriebssystem verhält – mit eigenem Init-System, eigenen Nutzern und Diensten).

Was Docker eigentlich ist

Docker ist eine Container-Laufzeitumgebung für Anwendungen, kein Hypervisor. Ein Docker-Container verpackt eine App – etwa eine Django-API oder ein Next.js-Frontend – zusammen mit ihren exakten Abhängigkeiten in ein Image und führt dieses Image dann als isolierten Prozess aus, der sich den Kernel des Hosts teilt. Mehr zum Unterschied zwischen Containern und virtuellen Maschinen erfahren Sie in unserem Vergleich Docker vs. virtuelle Maschinen, falls Ihnen die Grundlagen noch neu sind.

Das mentale Modell unterscheidet sich von einer VM oder einem LXC-Systemcontainer: Ein Docker-Container ist als wegwerfbar gedacht. Sie patchen ihn nicht im laufenden Betrieb – Sie bauen das Image neu und ersetzen den Container. Das ist eine bewusste Design-Entscheidung, keine Einschränkung.

LXC vs. Docker: beides Container, aber nicht dieselbe Aufgabe

Hier liegt die eigentliche Verwirrung, denn „LXC" und „Docker" sind beides Container, und viele nehmen an, austauschbar bedeute identisch.

LXC (Proxmox' Systemcontainer) sind darauf ausgelegt, sich wie ein leichtgewichtiges vollständiges Betriebssystem zu verhalten: eigener Init-Prozess, eigene systemd-Dienste, mehrere langlaufende Prozesse, persistenter Zustand, den Sie wie bei einer kleinen VM verwalten. Damit würden Sie zum Beispiel einen vollständigen Samba-Dateiserver oder eine Pi-hole-Installation betreiben, die sich wie eine dedizierte Box verhält.

Docker-Container sind darauf ausgelegt, einen einzelnen Prozess auszuführen, standardmäßig zustandslos zu sein und ständig neu erstellt zu werden. Mit Docker betreiben Sie Ihren App-Stack – eine Datenbank, eine API, ein Frontend – jeweils als eigenen Container, orchestriert über eine Compose-Datei.

Hinweis

Wenn Sie sich dabei ertappen, in einem Docker-Container ein vollständiges Init-System, Cron und SSH zu installieren, haben Sie eigentlich einen LXC-Container mit Umwegen gebaut. Das ist das Warnsignal, dass Sie das falsche Werkzeug benutzen.

In meinem Homelab: die reale Topologie

Hier ist, was ich tatsächlich betreibe, denn die abstrakte Version dieses Arguments bringt weniger als die konkrete. Die Infrastruktur dieser Seite selbst läuft auf einem Proxmox-Host, und Docker berührt niemals direkt das Blech. Der Aufbau sieht so aus:

Proxmox VE, direkt auf dem physischen Server installiert – die Bare-Metal-Hypervisor-Ebene.
Eine dedizierte Debian-VM, erstellt und verwaltet über Proxmox, mit eigener zugewiesener CPU, RAM und Festplatte.
Docker und Docker Compose, installiert innerhalb dieser VM – nichts Docker-Bezogenes läuft auf dem Proxmox-Host selbst.
Anwendungscontainer (API, Datenbank, Frontend, Reverse Proxy), die als Docker-Compose-Dienste innerhalb der VM laufen.
Alles mit Web-Zugriff sitzt hinter einem Reverse Proxy und wird aus derselben VM heraus exponiert – wenn Sie den Fernzugriff darauf zusätzlich absichern wollen, lohnt sich ein Blick auf unseren Vergleich WireGuard vs. OpenVPN.

Der Proxmox-Host bleibt bewusst langweilig: Er betreibt nur VMs. Die gesamte App-seitige Komplexität – Image-Builds, Container-Neustarts, Abhängigkeits-Updates – lebt innerhalb der Docker-VM, wo sie den darunterliegenden Hypervisor nicht destabilisieren kann.

Sollte Ihr Docker-Host eine VM oder ein LXC-Container sein?

Das ist die eigentliche Entscheidung, die sich hinter „Proxmox vs. Docker" verbirgt, und sie verdient eine klare Antwort.

Eine VM gibt Docker einen eigenen vollständigen Kernel, komplett getrennt vom Kernel des Proxmox-Hosts. Das bedeutet saubere Isolation, unkomplizierte Live-Migration und Snapshots, und keine seltsamen Wechselwirkungen zwischen der Kernel-Version des Hosts und dem, was Docker erwartet. Es kostet etwas mehr RAM-Overhead als ein LXC, aber das ist ein kleiner Preis für Stabilität.

Ein LXC-Container teilt sich den Kernel des Proxmox-Hosts, weshalb das Betreiben von Docker darin das Aktivieren von Nesting-Funktionen erfordert (`nesting=1`, manchmal `keyctl=1`) und in vielen Setups einen privilegierten Container. Das kann für vertrauenswürdige, unkritische Workloads funktionieren und ist ressourcenschonender.

Warnung

Docker in einem privilegierten LXC ist eine bekannte Homelab-Falle. Es bricht regelmäßig bei Upgrades des Proxmox-Kernels oder der LXC-Version, und privilegierte Container schwächen genau die Isolation, die LXC eigentlich bieten soll. Proxmox' eigene Dokumentation zu Linux-Containern empfiehlt, Container in einer VM zu verschachteln, wenn Isolation und Live-Migration wichtig sind – genau deshalb ist das oben beschriebene Docker-in-VM-Muster das, was ich produktiv einsetze, kein reiner Hobby-Kompromiss.

Wenn Sie nur experimentieren, ist ein LXC mit aktiviertem Nesting in Ordnung. Wenn Sie etwas betreiben, auf das Sie wirklich angewiesen sind – einschließlich einer Live-Website –, gehört Docker in eine VM.

Proxmox vs. Docker: nebeneinander nach Ebene

Ebene	Virtualisierungstyp	Isolation	Ressourcennutzung	Wofür gedacht	Backup/Snapshot
Proxmox	Type-1-Hypervisor (KVM für VMs, LXC für Systemcontainer)	Hardware-Ebene via KVM; Kernel geteilt via LXC	Schwerer pro VM, leichter pro LXC	Betrieb ganzer Betriebssysteme und Infrastruktur	VM-Snapshots + `vzdump`-Backups
Docker	Laufzeitumgebung für Anwendungscontainer	Prozess-Ebene, teilt sich den Host-Kernel	Sehr leicht – Container starten in Sekunden	Verpacken und Betreiben je einer Anwendung pro Container	Image-Neubauten + Volume-Backups, keine Hypervisor-Snapshots

Lesen Sie die Zeile „Wofür gedacht" und das gesamte Argument fällt auf einen Satz zusammen: Proxmox betreibt Maschinen, Docker betreibt Apps.

Was brauchen Sie wirklich?

Wenn Sie Hardware virtualisieren – einen Server in mehrere isolierte Betriebssystem-Instanzen aufteilen –, ist das Proxmox' Aufgabe. Wenn Sie eine Anwendung samt Abhängigkeiten verpacken und betreiben, ist das Dockers Aufgabe. In einem echten Homelab nutzen Sie beides, geschichtet: Proxmox erstellt die VM, Docker läuft darin. Falls Sie sich noch nicht einmal für den Hypervisor selbst entschieden haben, bevor Sie zu dieser Frage kommen, hilft unser Vergleich Proxmox vs. VMware vs. Hyper-V bei dieser vorgelagerten Entscheidung. Und falls Ihnen noch die passende Hardware dafür fehlt, lohnt sich ein Blick auf unseren Vergleich der besten Mini-PCs für einen Heimserver.

Es gibt kein Szenario in einem selbst gehosteten Homelab, in dem „Docker statt Proxmox" oder „Proxmox statt Docker" wirklich die richtige Frage ist. Die richtige Frage lautet, wo in Ihrer Proxmox-Topologie Docker leben sollte – und für alles, worauf Sie wirklich angewiesen sind, lautet die Antwort: in einer VM.

Häufige Fragen

Ersetzt Docker Proxmox?

Nein. Docker ist eine Laufzeitumgebung für Anwendungscontainer; Proxmox ist ein Bare-Metal-Hypervisor. Docker braucht ein Betriebssystem, auf dem es laufen kann – in einem Proxmox-Homelab ist das meist eine VM, die Proxmox erstellt hat.

Kann ich Docker direkt auf dem Proxmox-Host betreiben?

Technisch ja, aber es wird nicht empfohlen. Der Proxmox-Host soll der Virtualisierung vorbehalten bleiben; Anwendungscontainer direkt darauf zu betreiben vermischt Hypervisor- und App-Ebene und macht Upgrades riskanter. Eine dedizierte VM hält beides sauber getrennt.

Ist LXC dasselbe wie Docker?

Nein. Beides sind Container, aber LXC baut leichtgewichtige vollständige Betriebssysteme (mit eigenem Init-System und Diensten), während Docker eine einzelne Anwendung samt Abhängigkeiten in ein wegwerfbares, neu erstellbares Image verpackt.

Sollte ich für Docker auf Proxmox eine VM oder einen LXC-Container verwenden?

Nutzen Sie eine VM für alles, worauf Sie angewiesen sind. Eine VM gibt Docker einen komplett getrennten Kernel und vermeidet die Nesting- und Privileged-Container-Probleme, die Docker-in-LXC über Upgrades hinweg fragil machen. LXC mit aktiviertem Nesting ist für risikoarme Experimente in Ordnung.

Brauche ich Proxmox, um Docker zu Hause zu betreiben?

Nein – Docker läuft problemlos auf einer normalen Linux-Installation, einem Raspberry Pi oder einer einzelnen dedizierten Maschine. Proxmox wird nützlich, sobald Sie mehrere isolierte Umgebungen (eine Docker-VM neben anderen VMs und Diensten) auf einer physischen Box statt separater Hardware für jede betreiben möchten.