Docker vs. LXC in Proxmox: Wann was?

Docker ist allgegenwärtig. LXC ist die native Proxmox-Container-Technologie. Der Fehler ist, sie als Konkurrenten zu sehen — sie sind komplementär.

Proxmox VE — Weboberfläche mit Knoten und Gästen — In der Proxmox-VE-Oberfläche laufen LXC-Container und VMs nebeneinander auf demselben Host.

LXC: Der Proxmox-Native

LXC-Container in Proxmox verhalten sich wie schlanke VMs. Sie booten ein vollständiges Betriebssystem, haben systemd, bekommen eine eigene IP und lassen sich wie eine VM verwalten — Snapshot, Migration, Backup per PBS.

Der Overhead ist minimal, weil sie denselben Kernel wie der Host nutzen. Das macht LXC ideal für Dienste, die keine speziellen Kernel-Module brauchen: Webserver, Datenbanken, kleine Python-Dienste.

Privilegiert oder unprivilegiert?

Proxmox legt LXC standardmässig unprivilegiert an — und dabei sollte es bleiben. Root im Container ist dann eben nicht Root auf dem Host (User-Namespace-Mapping), was die Angriffsfläche entscheidend verkleinert. Privilegierte Container braucht man nur für Sonderfälle (bestimmte Mounts, GPU-Durchreichung) — und sollte dann genau wissen, warum.

Docker: Der App-Container

Docker verpackt Anwendungen mit allen Abhängigkeiten in ein Image. Es läuft nicht nativ auf Proxmox — entweder in einer VM oder, pragmatisch, in einer schlanken Ubuntu-LXC, die Docker hostet.

# In einer LXC: Docker installieren, dann:
docker run -d --name metabase -p 3000:3000 metabase/metabase

Docker ist stark für isolierte Applikationen, die mit einem Befehl starten sollen und deren Upstream-Images gepflegt werden. Uptime Kuma, Metabase, n8n, Paperless-ngx — alles Docker-first.

Der Docker-in-LXC-Fallstrick

Wer Docker in einer LXC fahren will, muss am Container das Feature nesting=1 (und je nach Image keyctl=1) setzen — sonst scheitert der Docker-Daemon kommentarlos. Offiziell empfiehlt Proxmox Docker in einer VM; die LXC-Variante ist die pragmatische Abkürzung, die man bewusst und mit diesem Wissen wählt.

Die Entscheidungsmatrix

Kriterium	LXC	Docker
Proxmox-Integration (Snapshot, Migration)	Voll	Nur via VM
Image-Bau & Reproduzierbarkeit	Aufwendig	Dockerfile, trivial
Upstream-Images	Selten	Standard
Persistente Daten	Bind-Mount / Container-FS	Volumes oder Bind-Mounts
Isolation	Unprivilegiert: gut	Kernel-geteilt oder VM-getrennt
Wartung (OS-Updates)	Wie VM, apt update	Image neu bauen/pullen

Unsere Faustregel

Docker in einer dedizierten VM für Applikationen, die Docker-Images bevorzugen — eine VM mit Ubuntu Server und Docker, die nur dafür existiert. Proxmox sichert die ganze VM per PBS.
Reine LXC für Datenbanken (PostgreSQL, SQL Server auf Linux) und selbstgeschriebene Dienste — wegen Snapshot-Fähigkeit und PBS-Integration ohne Zusatzschicht. Persistente Daten landen sauber auf einem Bind-Mount.
Niemals Docker direkt auf dem Proxmox-Host — das verschmutzt den Hypervisor und untergräbt die Trennung.

Der typische Fehler

Alles in Docker zu stecken, auch PostgreSQL, auch die 500-GB-Datenbank. Dann ein Docker-Update, das Volume-Verhalten ändert sich, und das Produktivsystem steht. Datenbanken gehören in LXC oder VMs — wegen Stabilität, nicht wegen Dogma.

Fazit

LXC und Docker schliessen sich nicht aus. LXC für System-Dienste mit langem Lebenszyklus, Docker für Applikationen mit fertigen Images und kurzer Lebensdauer. Die Kunst ist, sie in derselben Infrastruktur parallel zu betreiben, ohne dass sie sich ins Gehege kommen.