Docker vs. VM: Wann was einsetzen?

Sie haben eine freie Kiste oder einen frischen Proxmox-Node und einen Dienst, den Sie selbst hosten wollen. Das Tutorial, dem Sie folgen, sagt "starten Sie einfach einen Container". Der Forenbeitrag vom letzten Jahr sagt "bauen Sie einfach eine VM". Beides kann nicht die offensichtliche Antwort sein, und die falsche Wahl bedeutet entweder verschwendeten RAM oder einen Neuaufbau in einem Monat.

Die Verwirrung ist nachvollziehbar — Docker und virtuelle Maschinen lassen Sie beide isolierte Software auf gemeinsamer Hardware laufen, und viele Artikel verwenden "Container" und "VM" fast austauschbar. Es sind nicht dieselben Werkzeuge, und meistens konkurrieren sie auch gar nicht um denselben Job.

TL;DR

Eine VM virtualisiert Hardware — jede bootet ein komplettes Betriebssystem samt Kernel, was zig Sekunden dauert und Hunderte Megabyte Overhead kostet.
Ein Docker-Container teilt sich den Host-Kernel und startet in unter einer Sekunde mit einem Bruchteil des Overheads.
VMs gewinnen bei der Isolationsstärke; Docker gewinnt bei Geschwindigkeit, Dichte und Portabilität.
Die meisten Self-Hoster entscheiden sich nicht für eines von beiden — sie betreiben Docker innerhalb einer VM, worum es in diesem Artikel eigentlich geht.

Was eine virtuelle Maschine wirklich ist

Eine virtuelle Maschine ist die Illusion eines Hypervisors, einen kompletten Computer bereitzustellen. Software wie Proxmox VE, VMware oder Hyper-V teilt Ihre physische CPU, Ihren RAM und Ihren Speicher auf und gibt jeder VM ihre eigene virtuelle Hardware. Jede VM bootet ihren eigenen Kernel und ihr eigenes vollständiges Betriebssystem auf dieser virtuellen Hardware — genau so, als wäre sie eine separate physische Maschine.

Deshalb kann eine VM ein völlig anderes Betriebssystem als ihr Host ausführen — eine Windows-VM auf einem Linux-Hypervisor oder umgekehrt. Wenn Sie noch entscheiden müssen, welchen Hypervisor Sie dafür nutzen, führt Sie der Vergleich Proxmox vs. VMware vs. Hyper-V fürs Homelab durch die Abwägungen.

Der Preis dieser Vollständigkeit ist Gewicht. Jede VM trägt ihren eigenen Kernel, ihre eigenen Betriebssystemdienste und ihren eigenen Speicher-Fußabdruck, bevor Ihre eigentliche Anwendung überhaupt etwas getan hat.

Was ein Docker-Container wirklich ist

Ein Docker-Container ist keine kleine VM. Es ist ein Prozess auf dem Host, isoliert über Linux-Namespaces (sodass er die Dateien, das Netzwerk oder die PIDs anderer Prozesse nicht sehen kann) und Cgroups (die seine CPU- und Speichernutzung begrenzen). Entscheidend ist: er teilt sich den Kernel der Host-Maschine — darunter bootet kein zweites Betriebssystem.

Docker rahmt das in der eigenen Dokumentation ganz nüchtern ein: Container sind "leichtgewichtig und schnell", genau weil sie den Hypervisor und das vollständige Gast-Betriebssystem überspringen, das eine VM benötigt, so die offizielle Docker-Übersicht. Wenn Sie noch nicht mit Docker gearbeitet haben, sind unser Vergleich Proxmox vs. Docker — was läuft wo und ein passender Mini-Server aus dem Ratgeber zum besten Mini-PC fürs Homelab 2026 gute Ausgangspunkte, bevor dieser Vergleich für Sie greifbar wird.

Warum das geteilte Kernel-Prinzip die Wurzel von allem anderen ist

Jeder andere Unterschied in diesem Artikel — Bootzeit, Speicher-Overhead, Isolationsstärke — lässt sich auf eine einzige Tatsache zurückführen: Eine VM bootet einen Kernel, ein Container leiht sich einen. Genau diese architektonische Entscheidung macht Container schnell und leicht — und genau deshalb sind sie keine Sicherheitsgrenze auf Hardware-Ebene, wie es eine VM ist.

Container liefern auch kein vollständiges Dateisystem-Image wie eine VM-Festplatte — sie werden aus gestapelten, wiederverwendbaren Image-Layern gebaut, was ein großer Grund für ihre Portabilität und schnelle Ladezeiten ist. Wie Ihre Dienste auf dieser gemeinsamen Basis am Ende tatsächlich betrieben werden, zeigt der Vergleich TrueNAS vs. Unraid — welches NAS-Betriebssystem gewinnt, falls Sie den Unterbau noch nicht festgelegt haben.

Bootzeit, Overhead und Dichte: die Zahlen, die zählen

Hier hört der Unterschied auf, theoretisch zu sein.

Eine VM muss einen vollständigen Kernel und ein Betriebssystem booten, bevor Ihre Anwendung überhaupt startet — das dauert typischerweise etwa 15 Sekunden bis zu einer Minute oder länger, selbst bei optimierten Templates. Ein Docker-Container überspringt das komplett — weil er nur ein Prozess ist, der einem bereits laufenden Kernel beitritt, erreicht er einen einsatzbereiten Zustand üblicherweise in unter einer Sekunde.

KEY-STAT: Container starten üblicherweise in unter 1 Sekunde gegenüber etwa 15–60+ Sekunden für einen VM-Boot — Quelle: unabhängige Container/VM-Benchmark-Vergleiche, 2026

Bei Speicher zeigt sich dasselbe Muster. Eine minimale VM-Installation trägt eine Grundlast von mehreren Hundert Megabyte oder mehr allein für ihr eigenes Betriebssystem, bevor Ihre App überhaupt etwas anfasst — so eine vergleichende Analyse von Northflanks Containers-vs-VMs-Aufschlüsselung. Container hingegen teilen sich Basis-Image-Layer im Speicher über mehrere Instanzen hinweg, weshalb dasselbe RAM-Budget, das komfortabel ein gutes Dutzend VMs betreibt, oft weit über hundert Container stemmen kann.

Tipp

Wenn Sie eine Handvoll leichtgewichtiger Dienste betreiben (ein Reverse-Proxy, eine kleine Datenbank, eine Dashboard-App), passen davon mit Containern fast immer mehr in denselben RAM als mit separaten VMs.

Diese Dichte-Lücke ist auch der Grund, warum der eigene Ressourcen-Fußabdruck von Docker Desktop nicht nur für Server, sondern auch für lokale Entwicklungsrechner zählt — ein großer Teil davon, warum Docker sich laut eigenen Preis- und Produktseiten als die leichtgewichtigere Option für Einzelpersonen und kleine Teams positioniert (Docker Desktop bleibt im Personal-Plan kostenlos für Einzelpersonen, Studierende und Unternehmen mit weniger als etwa 250 Mitarbeitenden und 10 Millionen Dollar Umsatz; größere kommerzielle Nutzung erfordert ein kostenpflichtiges Pro-, Team- oder Business-Abo).

Sicherheit und Isolation: der Kompromiss, der nirgends auf dem Etikett steht

Hier kommt der Teil, der bei "nutzt einfach Container"-Ratschlägen gerne unter den Tisch fällt.

Weil eine VM Hardware virtualisiert, wird eine kompromittierte VM durch die Hypervisor-Grenze eingedämmt — sie kann in der Regel ohne einen Exploit auf Hypervisor-Ebene nicht auf den Host oder andere VMs zugreifen, und solche Exploits sind selten und werden intensiv geprüft. Weil ein Container sich den Kernel des Hosts teilt, hat eine Schwachstelle auf Kernel-Ebene einen deutlich größeren Explosionsradius: im schlimmsten Fall könnte sie jeden Container auf diesem Host betreffen, nicht nur einen.

Warnung

Namespaces und Cgroups sind eine starke Prozessisolation, aber sie sind keine gleichwertige Alternative zur Hardware-Virtualisierung. Führen Sie wirklich nicht vertrauenswürdigen oder feindseligen Code nicht in einem nackten Container aus, so wie Sie ihn sicher in einer dedizierten VM sandboxen könnten.

Genau deshalb lautet das Branchenmuster nicht "Container haben VMs ersetzt", sondern "Container laufen innerhalb von VMs". Multi-Tenant-Cloud-Plattformen betreiben ihre Container-Flotten überwiegend innerhalb von VMs, gerade um diese Hypervisor-Grenze zwischen Mandanten aufrechtzuerhalten — sie legen Dockers Geschwindigkeit auf die Isolation einer VM, statt sich für eine der beiden Garantien zu entscheiden.

Hinweis

Wenn ein Dienst wirklich gegenseitig misstrauische Workloads isolieren muss (nicht nur Ihre eigenen Apps aufräumen soll), tendieren Sie zu VM-Ebene-Trennung oder mindestens zu einer gehärteten Container-Runtime — nicht zu einem nackten Container auf geteiltem Kernel.

Portabilität und Packaging: hier gewinnt Docker klar

Das ist die eine Dimension ohne echten Kompromiss. Ein Docker-Image ist ein versioniertes, geschichtetes Artefakt, das auf jeder Maschine mit Docker-Engine identisch läuft — Ihrem Laptop, einer Homelab-Kiste oder einer Cloud-VM. Ein VM-Image oder -Template ist im Vergleich dazu ein vollständiges Disk-Image: viele Gigabyte groß, langsamer zu verschieben und selten so trivial über verschiedene Hypervisor-Plattformen hinweg reproduzierbar.

Diese Reproduzierbarkeit — "es läuft überall gleich" — ist der wichtigste Grund, warum Docker sich beim Anwendungs-Packaging durchgesetzt hat, selbst in Umgebungen, die aus Isolationsgründen weiterhin alles in VMs betreiben.

In meinem Homelab: warum ich Docker in einer VM betreibe, nicht statt einer

In meinem Homelab behandle ich das nicht als Entweder-oder-Entscheidung. Ich betreibe eine dedizierte VM auf meinem Proxmox-Host, und Docker läuft innerhalb dieser VM und hostet die eigentlichen Dienste.

Die VM gibt mir eine harte Grenze: Wenn innerhalb des Container-Stacks etwas schiefgeht — ein schlechtes Update, ein sich falsch verhaltendes Image, eine Abhängigkeit, der ich nicht voll vertraut habe —, bleibt es auf diese eine VM begrenzt und treibt nicht frei auf dem Hypervisor neben meinen anderen VMs. Ich kann die gesamte VM vor einer riskanten Änderung snapshotten und bei Problemen in Sekunden zurückrollen.

Docker gibt mir, innerhalb dieser VM, genau das, worin VMs schwach sind: einen neuen Dienst in unter einer Sekunde hochziehen, ein versioniertes Image pullen statt ein Betriebssystem von Hand zu konfigurieren, und ein Dutzend-plus kleiner Dienste auf Hardware betreiben, die sich mit einem Dutzend-plus separater VMs schwertun würde. Ich bekomme die Isolationsgrenze der VM und die Geschwindigkeit und Dichte von Docker gleichzeitig, statt das eine gegen das andere eintauschen zu müssen.

Die Entscheidungsmatrix: Docker vs. VM auf einen Blick

Dimension	Docker-Container	Virtuelle Maschine
Bootzeit	Unter 1 Sekunde (tritt laufendem Kernel bei)	~15–60+ Sekunden (bootet volles OS/Kernel)
Ressourcen-Overhead	Niedrig; teilt Basis-Image-Layer im Speicher	Höher; mehrere Hundert MB+ Grundlast pro Instanz
Isolationsstärke	Prozessebene (Namespaces, Cgroups); teilt Host-Kernel	Hardware-Ebene via Hypervisor; eigener Kernel pro VM
Dichte pro Host	Oft 100+ Container auf Hardware, die ~10–15 VMs fasst	Niedriger, wegen Overhead durch volles OS pro Instanz
Portabilität	Sehr portables Image, läuft überall identisch, wo Docker läuft	Schwerer; Disk-Images sind groß und weniger trivial portabel
OS-Flexibilität	An die OS-Familie des Host-Kernels gebunden	Kann ein komplett anderes OS/Kernel als der Host ausführen
Bester Einsatzfall	App oder Dienst schnell packen und ausführen	Harte Isolation, ein anderes OS oder nicht vertrauenswürdige Workloads

Wann was tatsächlich gewinnt

Greifen Sie zu Docker, wenn Sie eine Anwendung packen oder ausführen, schnelle Iteration wollen und keinen anderen Kernel oder ein anderes OS als Ihr Host bereits liefert benötigen. Es ist die richtige Standardwahl für die meisten selbst gehosteten Dienste: ein Media-Server-Backend, eine kleine Datenbank, einen Monitoring-Stack.

Greifen Sie zu einer VM, wenn Sie ein wirklich anderes Betriebssystem brauchen, eine harte Isolationsgrenze für etwas, dem Sie nicht voll vertrauen, oder einen sauberen Rollback-Punkt via Snapshots, den ein Container allein nicht bietet.

Greifen Sie zu beidem zusammen — Docker innerhalb einer VM —, wenn Sie ein Homelab aufbauen und die Explosionsradius-Eindämmung der VM zusammen mit der Geschwindigkeit und dem Packaging-Komfort des Containers wollen. Diese Kombination, nicht ein einzelner Gewinner, ist das, was die meisten produktiven Container-Plattformen und die meisten ernsthaften Homelabs tatsächlich fahren.

Häufige Fragen

Ist Docker schneller als eine virtuelle Maschine?

Ja, beim Start: Ein Docker-Container erreicht typischerweise in unter einer Sekunde einen einsatzbereiten Zustand, weil er sich den bereits laufenden Kernel des Hosts teilt, während eine VM zuerst ihr eigenes vollständiges Betriebssystem und ihren Kernel booten muss, was üblicherweise 15 Sekunden bis über eine Minute dauert.

Kann Docker virtuelle Maschinen komplett ersetzen?

Nein. Docker ist beim Packaging und Ausführen von Anwendungen schneller und leichter, kann aber weder die Isolation auf Hardware-Ebene noch die Möglichkeit bieten, ein anderes OS/Kernel auszuführen, das eine VM liefert — deshalb betreibt die meiste Infrastruktur Docker-Container innerhalb von VMs statt anstelle von ihnen.

Ist Docker weniger sicher als eine VM?

Docker-Container teilen sich den Host-Kernel, daher hat eine Schwachstelle auf Kernel-Ebene einen größeren potenziellen Explosionsradius als eine kompromittierte VM, die die Hypervisor-Grenze in der Regel eindämmt. Namespaces und Cgroups bieten solide Prozessisolation, sind aber keine gleichwertige Alternative zur Hardware-Virtualisierung.

Kann man Docker innerhalb einer virtuellen Maschine betreiben?

Ja, und das ist ein sehr verbreitetes Muster — auch im eigenen Homelab dieses Autors. Docker innerhalb einer VM zu betreiben, kombiniert die harte Isolationsgrenze der VM mit dem schnellen Start, dem geringen Overhead und dem einfachen Image-basierten Packaging von Docker.

Brauchen Docker-Container ein eigenes Betriebssystem?

Nein. Ein Container packt Ihre Anwendung und ihre Abhängigkeiten, läuft aber über den bereits vorhandenen Kernel der Host-Maschine, statt ein separates Betriebssystem zu booten — der Hauptgrund, warum Container schneller starten und weniger Speicher als VMs benötigen.