Proxmox 9.1 kann „Docker-Container ausführen" … aber nicht so, wie Sie denken

An dem Morgen, an dem das Feature landete, lehnte sich irgendwo ein Cluster-Admin vermutlich in seinem Stuhl zurück, kniff die Augen vor dem Proxmox-9.1-Changelog zusammen und murmelte: „Kein Weg, dass sie das wirklich gemacht haben." Jahrelang war das Ausführen von Docker auf Proxmox in irgendeiner „nativen" Form so etwas wie ein Homelab-Tagtraum. Klar, manche wickelten Docker in LXCs ein, andere steckten es in schlanke VMs, und einige abenteuerlustige Seelen taten so, als sei alles in Ordnung, während sie die gelegentliche Kernel-Beschwerde ignorierten. Jeder hatte seinen eigenen Hack. Jeder hatte seine eigenen Narben.

Doch Proxmox 9.1 brachte einen neuen Trick: OCI-basierte Container, die wie schlanke LXC-Guests aussehen, direkt aus Docker-Images hochgezogen. Über Nacht erwachte eine Ecke der Infrastruktur-Welt zum Leben — mit Beiträgen, Kommentaren und YouTube-Erklärvideos, manche begeistert, manche verwirrt, manche mit der Warnung an andere, um der Verfügbarkeit willen erst einmal durchzuatmen, bevor man kopfüber einsteigt.

Und der beste Weg, wirklich zu verstehen, wie dieses Feature ankam, ist, den Leuten zuzuhören, die es in den ersten Stunden auf Herz und Nieren geprüft haben. Das Fazit? Proxmox hat den Nutzern technisch gesehen einen Weg gegeben, „Docker-Container auszuführen", aber was sie tatsächlich bekommen haben, ist ein sehr proxmox-typischer Hybrid — clever, vielversprechend, ein bisschen seltsam und ganz sicher kein Docker-Ersatz. Zumindest noch nicht.

Die erste Reaktion: hoffnungsvoll, aber vorsichtig

Eine frühe Reaktion traf die Stimmung genau: „Ich werde meine VMs wohl noch nicht ersetzen, aber ich mag die Idee und die Richtung." Viele Leute betreiben Container mit Portainer in einer dedizierten VM, weil das saubere Isolation, Namespacing und vertraute Docker-Semantik liefert. Diese Nutzer reißen ihr Setup nicht über Nacht ein.

Jemand anderes gab zu, Dockers Umgang mit Namespaces viel zu sehr zu mögen, um ihn aufzugeben. Für diese Person war das Stapeln von Containern mit sauberen Netzwerkgrenzen und unter einer einzigen IP gruppierten Ports nicht nur eine Annehmlichkeit — es ist die Grundlage des gesamten Self-Hosted-Designs. Und genau darum waren mehrere Leute enttäuscht, dass sich die OCI-Container von Proxmox wie LXCs verhalten: Jeder bekommt seine eigene IP. Das ist der ganze Deal. Wollen Sie ein Dutzend Dienste an einer IP mit verschiedenen Ports hängen? Pech gehabt. Ein Reverse Proxy könnte helfen, aber das war nicht der Punkt.

Trotzdem sah die Gruppe mit knappen Ressourcen echtes Potenzial. Volle VMs für winzige Dienste zu betreiben fühlt sich verschwenderisch an, und LXCs, die Docker hosten, können je nach Kernel-Features seltsam werden. Dass Proxmox einen containerartigen Workload ohne Docker, Podman oder irgendeine OS-Schicht bereitstellen kann — das ist für kleine Maschinen gewaltig.

Aber dann kam die Frage, die den Ton für den Rest des Threads setzte: „Was ist der eigentliche Anwendungsfall?"

Es stellte sich heraus, dass die Leute reichlich Antworten hatten. Und reichlich Vorbehalte.

Die erste Welle der Verwirrung: Moment, wie funktioniert das eigentlich?

Das häufigste Missverständnis, das sich wie eine Brise durch den Thread verbreitete? Die Vorstellung, Proxmox würde „Docker in Containern" ausführen.

Mehrere Leute versuchten das zu korrigieren — manche sanft, manche weniger sanft.

Mehrere Kommentatoren betonten denselben Kernpunkt: Proxmox wandelt ein OCI-Image in ein LXC um. Das bedeutet, der Container-Inhalt aus dem Image wird zu einem schlanken Dateisystem für einen privilegierten LXC-Guest. Es gibt keine Docker-Engine. Kein Podman. Keinen Docker-Daemon. Sie rufen kein docker ps auf. Sie beobachten keinen Docker-Socket. Sie machen keine Multi-Container-Stacks.

Es ist eher so:

1. Ein Docker-Image herunterladen
2. Dessen Dateisystem entpacken
3. Das als Root-FS für ein LXC verwenden
4. Als Systemdienst starten

Das ist clever, lädt aber auch Ärger ein, wenn das Image ein Verhalten erwartet, das nur eine Docker-Laufzeitumgebung liefert — Dinge wie ephemere Resets, konsistente Mounts, Netzwerkannahmen oder Overlay-Dateisystemverhalten.

Unverblümt gesagt: Docker-Images wurden nicht dafür gebaut, vollständige Root-Dateisysteme zu sein. Und das kann einem auf die Füße fallen.

Deshalb schrieb ein Kommentator schlicht: „Die meisten Docker-Container funktionieren bei mir nicht. Deshalb ist das ein Technik-Review."

Genau. Da haben wir's.

Das Update-Problem

Fast alle waren sich über das größte Kopfzerbrechen einig: Das Aktualisieren von OCI-Containern auf Proxmox ist derzeit umständlich.

Wenn Sie einen OCI-Container in Docker neu bauen, ziehen Sie einfach und starten neu. Die Laufzeitumgebung fegt die neuen Layer herein. Das ephemere Design des Containers erspart Ihnen die Sorge, was mit dem darunterliegenden Root-FS passiert.

Auf Proxmox? Ihr aus OCI abgeleitetes LXC verhält sich wie jedes andere LXC: Es hat einen Zustand. Wenn Sie nicht auf gemounteten Storage achten, bedeutet ein Update:

1. Eine neue Instanz bauen
2. Mounts neu anhängen
3. Konfiguration kopieren
4. Den alten Container ersetzen

Das ist nicht elegant. Ein YouTuber empfahl diesen Ansatz für den Moment, und ehrlich gesagt muss es so bleiben, bis Proxmox einen echten Update-Workflow hinzufügt.

Ein Nutzer fasste es treffend zusammen:

„Vielleicht nutze ich statt Volumes einfach SMB — falls das überhaupt funktioniert, keine Ahnung."

Da stehen wir gerade.

Mounts, Netzwerk und die seltsamen Ecken

Mehrere Nutzer stießen früh auf Einschränkungen:

Geteilte Mounts sind nicht offensichtlich

Jemand versuchte, SMB-Shares zu mounten, und stieß an eine Wand. Andere wiesen darauf hin, dass LXCs lokale Bind-Mounts durchaus unterstützen — nur nicht auf eine Weise, die das Docker-Volume-Verhalten sauber nachahmt.

Netzwerk verhält sich wie LXC, nicht wie Docker

Wer an Dockers Modell „eine IP, viele Ports" gewöhnt ist, empfindet den Wechsel zu „jeder Container hat einen vollständigen IP-Stack" als hart. Proxmox weist seinen OCI-Containern automatisch Netzwerkkonfigurationen wie bei LXCs zu, einschließlich MAC-Adressen, Bridges und Firewall-Regeln.

Ein Reverse Proxy behebt das, aber das ist zusätzliche Verkabelung, mit der die Leute nicht gerechnet hatten.

Keine Multi-Container-Setups

Compose? Stacks? Immich-Fans fragten danach. Die Antwort war durchgängig: nein, im Moment nicht.

Kein Docker-Daemon bedeutet keine Orchestrierungsschicht. Jeder OCI-Container ist eine einzelne Laufzeitumgebung: eine App, ein Root-FS, ein Startbefehl. Großartig für kleine Dienste. Furchtbar für alles, was komplexe Orchestrierung braucht.

Das YouTube-Chaos: Leute versuchen zu erklären … und streiten darüber

Kaum war das Feature draußen, stürzten sich die YouTuber natürlich darauf.

Manche mochten den Überblick von Techno Tim. Andere sagten, das Video habe Verwirrung gestiftet, weil es suggerierte, Container würden innerhalb von Containern laufen. Er stellte später klar, aber der Schaden war angerichtet — viele Zuschauer trugen das falsche mentale Modell davon.

Andere verwiesen auf eine technischere Aufschlüsselung und beharrten darauf, sie erkläre die Architektur besser.

Das war das Muster im gesamten Thread: Jede begeisterte Erklärung wurde von jemandem gekontert, der mit dem Feuerlöscher hinterherlief und rief: „NEIN! So funktioniert das nicht!"

Das passiert, wenn ein Feature früh, ungewöhnlich und schlecht dokumentiert ist.

Praktische Anwendungsfälle: Wo OCI-Container wirklich glänzen

Jenseits der Debatte tauchten mehrere reale Anwendungsfälle auf.

1. Ersatz für schlanke LXCs, die für einzelne Apps gedacht waren

Viele Leute betreiben Apps in LXCs, obwohl diese Apps eigentlich für Container gebaut wurden. Denken Sie an AdGuard, Unifi, kleine Netzwerktools oder Service-Manager. Aber LXCs brauchen weiterhin Patches, Paketverwaltung und OS-Pflege.

Eine Person fasste es so zusammen: „Ich will nicht als 2000er-Jahre-Sysadmin herumspielen und mich bei jedem Update mit Abhängigkeiten herumschlagen."

Mit OCI-Containern können Sie eine App über ihr Docker-Image betreiben — ohne Docker zu benutzen — und dabei die OS-Wartungssteuer umgehen.

2. Ressourcenbeschränkte Hardware

Leute, die Proxmox auf NUCs, Mini-PCs oder kleinen Heimservern betreiben, können sich manchmal den RAM-Overhead einer VM nicht leisten, nur um einen Docker-Daemon zu beherbergen.

OCI-Container geben ihnen minimalen Overhead mit dienstspezifischer Isolation.

3. Cluster-Netzwerk-Anwendungsfälle

Ein Nutzer erklärte, er habe ein dediziertes SDN-Netzwerk, isoliert vom Haupt-LAN. Er betreibt eine VM nur, um einen Reverse Proxy zu hosten. Das ist Overkill. Er versuchte Docker in einem LXC, bekam es aber nicht sauber zum Laufen.

Ein OCI-Container, gebaut aus dem Traefik-Image, löst genau dieses Problem mit minimalem Overhead.

Das ist sicher ein Nischen-Anwendungsfall. Aber das sind Homelabber. Jeder Anwendungsfall ist eine Nische.

Die Dealbreaker: Wo es heute noch hakt

Selbst die Optimisten gaben einige Schmerzpunkte zu.

1. Docker-Semantik ist einfach nicht da

Leute, die Updates über den Docker-Socket verfolgen? Tut mir leid. Der Socket existiert nicht.

Projekte, die eine Docker-Umgebung erwarten? Fehlanzeige.

Tools, die auf Docker-Events angewiesen sind? Passiert nicht.

2. Viele Container-Images laufen einfach nicht

Je mehr ein Image von Docker-Laufzeitfeatures abhängt statt nur von Dateisysteminhalten, desto wahrscheinlicher bricht es.

3. Zustandsbehaftete LXCs verhalten sich anders als ephemere Docker-Container

Jemand fragte: „Moment, setzt sich das Dateisystem zurück wie bei Docker?"

Die Antwort: nein.

Alles, was ins Root-FS schreibt, bleibt dort, es sei denn, Sie bauen es neu auf oder räumen manuell auf. Das ist nicht zwangsläufig schlecht, aber grundlegend anderes Verhalten.

4. Multi-Container-Workflows sind vom Tisch

Compose-basierte Apps — Immich, Home Assistant mit Add-ons, Datenbanken zusammen mit Frontends — lassen sich nicht sauber verwalten.

Die LXC-Fraktion: „Das machen wir schon seit Jahren"

Manche Leser waren fast amüsiert.

Menschen betreiben Docker in LXCs schon lange. Es funktioniert einigermaßen gut, besonders für unkritische Homelab-Setups. Ein paar erwähnten kleine Patches, die nach bestimmten Updates nötig waren, aber insgesamt sei das Setup stabil gewesen.

Für sie fühlen sich Proxmoxs OCI-Container also wie eine seitliche Variante dessen an, was sie ohnehin schon tun — nett, aber keine Revolution.

Sie wollen echtes Docker oder echtes Podman auf Host-Ebene integriert. Das ist nicht, was dieses Feature ist. Wenn Sie noch zwischen reinem LXC, Docker-in-LXC und einer vollen VM abwägen, geht unser Entscheidungsleitfaden LXC vs. VM vs. Docker die Abwägungen für jede Option durch.

Wo dieses Feature tatsächlich steht

Zusammengenommen zeichnet die Diskussion das Bild eines Features, das ist:

• Neu
• Seltsam
• Mächtig
• Missverstanden
• Nicht produktionsreif
• Und definitiv nicht „Docker auf Proxmox"

Noch nicht.

Was Proxmox tatsächlich gebaut hat, ist ein Weg, OCI-Images — eines der am weitesten verbreiteten Packaging-Formate der Tech-Welt — zu nehmen und sie als schlanke Systemcontainer zu booten, ohne eine Container-Laufzeitumgebung zu installieren.

Es ist clever.

Es ist nützlich.

Und es wird sich ganz sicher weiterentwickeln.

Im Moment sitzt es in einer eigenartigen Mittelspur: zu mächtig, um es zu ignorieren, zu unfertig, um sich darauf zu verlassen, und zu verwirrend, um es zu erklären, ohne einen Streit anzuzetteln.

Die Zukunft: Wann Proxmox Docker-Hosts wirklich ersetzen könnte

Wird sich dieses Feature irgendwann zu einem echten Docker-Ersatz für Homelab-Nutzer entwickeln?

Vielleicht.

Aber laut der Diskussion braucht es:

• Echte Update-Workflows
• Bessere Kompatibilitätsschichten für Images
• Multi-Container-Orchestrierung
• Sauberere Netzwerkoptionen
• Stabileres Dateisystemverhalten
• Bessere Dokumentation
• Und generell weniger Verwirrung

Wenn Proxmox das hinbekommt, würde es zu einer Anlaufstelle für Virtualisierung, leichtgewichtiges App-Hosting und Container-Workloads — etwas, an dem selbst TrueNAS noch arbeitet.

Im Moment ist es experimentell. Es ist vielversprechend. Und ehrlich gesagt macht es ziemlich Spaß, dabei zuzusehen, wie es sich entfaltet.

Schlusswort

Proxmox 9.1 hat Docker nicht obsolet gemacht. Es hat Sie nicht Ihre Compose-Dateien wegwerfen lassen. Es hat Sie nicht Ihren gesamten Heimstack in ein einziges Hypervisor-Feature zusammenfalten lassen.

Was es getan hat, ist eine Tür zu öffnen — eine Tür in eine Zukunft, in der Proxmox containerisierte Apps ohne schwergewichtige Laufzeitumgebungen oder fragile Hacks ausführen kann. Eine Tür, durch die Homelabber kleine Dienste schnell bereitstellen, OS-Wartung überspringen und VMs für Einzel-App-Workloads vermeiden können.

Es ist früh. Es ist unordentlich. Es ist missverstanden.

Aber es ist etwas Neues.

Und in einer Welt, in der jeder eine Meinung dazu hat, wie Container funktionieren sollten, hat Proxmox die Debatte gerade noch interessanter gemacht.