Container machine: Apples leiser Angriff auf Docker Desktop

Auf der WWDC26 stellt Apple mit „Container machine" eine Funktion vor, die auf den ersten Blick klein wirkt: eine persistente Linux-Umgebung auf dem Mac, schnell und leichtgewichtig wie ein Container, dauerhaft wie eine virtuelle Maschine.¹ Auf den zweiten Blick ist es der zweite Baustein einer Strategie, die Apple 2025 begonnen hat und die ein klares Ziel verfolgt. Apple baut den lokalen Container-Workflow auf dem Mac selbst, vorbei an Docker Desktop.

Die Frage „tötet Apple jetzt Docker" ist dabei falsch gestellt. Interessanter ist, welche Schicht des Docker-Stacks Apple angreift, welche es bewusst übernimmt, und warum ausgerechnet der Mac der Ort ist, an dem Docker Desktop am verwundbarsten ist.

Zwei Jahre, zwei Bausteine

Der Ausgangspunkt liegt ein Jahr zurück. Auf der WWDC25 hat Apple das Projekt Containerization quelloffen gestellt, ein in Swift geschriebenes Framework zum Ausführen von Linux-Containern auf macOS, lizenziert unter Apache 2.0 und optimiert für Apple Silicon.² Containerization liefert APIs für Storage, Networking, Ausführung und ein Linux-Init-System. Dazu kam das CLI-Werkzeug container, das Image-Erstellung, Distribution und Lifecycle-Management übernimmt, also genau die Aufgaben, für die man auf dem Mac bisher Docker Desktop, Colima oder Podman benutzt hat.

Containerization arbeitet mit OCI-kompatiblen Images aus Standard-Registries. Wer ein Image mit container baut, kann es in jede normale Registry pushen. An dieser Stelle liegt schon die erste wichtige Einordnung: Apple erfindet das Format nicht neu, es übernimmt den Industriestandard. Das ist kein Detail, sondern die Bedingung dafür, dass das Ganze überhaupt anschlussfähig ist.

container setzt strikte Anforderungen. Es läuft ausschließlich auf Apple Silicon und offiziell nur auf macOS 26. Die Projektdokumentation ist dabei ungewohnt deutlich: „We do not support older versions of macOS and the container maintainers typically will not address issues that cannot be reproduced on macOS 26."² Das Projekt ist außerdem noch vor Version 1.0, Minor-Releases dürfen brechende Änderungen einführen.

Container machine ist der zweite Baustein, gebaut auf demselben Fundament. Während ein klassischer Container für eine einzelne Anwendung gedacht ist und nach getaner Arbeit verschwindet, zielt Container machine auf etwas anderes: eine Linux-Umgebung, die bleibt.

Eine VM pro Container

Der architektonische Unterschied zu Docker ist die eigentliche Geschichte, und er erklärt fast alles Weitere.

Docker Desktop startet auf dem Mac eine einzige Linux-VM. In dieser VM läuft der Docker-Daemon, und in dieser einen VM laufen alle Container nebeneinander, im selben Kernel, im selben User-Space. Der Overhead der VM wird über alle Container amortisiert, geteilt wird aber auch der Kernel.

Apple geht den umgekehrten Weg. Jeder Container bekommt seine eigene leichtgewichtige virtuelle Maschine, direkt über Apples Virtualization.framework. In jeder dieser Mikro-VMs läuft ein minimales Init-System namens vminitd, dazu ein für den Zweck optimierter Linux-Kernel und ein minimales Root-Dateisystem. Das Resultat sind Startzeiten unter einer Sekunde, trotz vollständiger VM-Isolation. Ein ps aux auf dem Host zeigt nur die Container-Prozesse, der Rest ist sauber gekapselt.³

Der Trade-off liegt offen. Isolation gegen Amortisation:

Die Zahlen stammen aus Drittanalysen⁴, nicht aus offiziellen Apple-Benchmarks, und sie beschreiben Grundlasten, nicht den Gesamtverbrauch. Sie meinen den Overhead der leeren VM, der Speicher der laufenden Anwendung kommt in beiden Modellen obendrauf. Wichtig dabei: Dockers VM ist nicht starr. Ihr Limit liegt per Default bei der Hälfte des Host-RAM, der tatsächliche Verbrauch wächst elastisch mit der Last bis zu dieser Grenze.⁵ Ein Supabase-Stack aus rund einem Dutzend Diensten belegt in der gemeinsamen VM problemlos 5 GB und mehr, das ist erwartbar und kein Widerspruch zur niedrigen Grundlast.

Apples Skalierungsproblem liegt deshalb woanders, als ein simpler Pro-Container-Aufschlag vermuten lässt. Erstens vervielfacht sich der feste VM-Overhead: zwanzig Mikro-VMs schleppen zwanzig Kernel und zwanzig Init-Systeme mit, wo Docker einen einzigen Kernel teilt. Zweitens, und das wiegt schwerer, unterstützt das Virtualization.framework Memory-Ballooning nur teilweise.⁶ Eine Mikro-VM gibt ungenutzten Speicher kaum an den Host zurück. Laut The Register ist der Speicher per Default auf die Hälfte des System-RAM gesetzt und „cannot be released back to the host", ohne die VM neu zu starten.⁷ Dockers eine elastische VM holt sich Speicher nach Bedarf und gibt ihn wieder her, Apples Flotte einzelner VMs hält ihn fest.

Für den typischen lokalen Entwickler-Loop mit zwei, drei Containern gewinnt Apples Modell bei Isolation und Startzeit. Bei dichten Multi-Service-Stacks kehrt sich der Vorteil eher um, nicht weil Docker sparsamer wäre, sondern weil Apple den festen Overhead vervielfacht und Speicher schlechter zurückgibt.

Sicherheitstechnisch ist die Sache eindeutiger. Eine eigene VM pro Container bedeutet Hardware-gestützte Isolation statt geteiltem Kernel. Ein Ausbruch aus einem Container landet nicht im gemeinsamen Kernel aller anderen, sondern in einer leeren Mikro-VM. Das ist der Punkt, an dem Apple sein Lieblingsargument spielt, Security und Privacy, und hier trägt es technisch.

Container machine ist Apples Antwort auf WSL

Container machine nimmt diese Architektur und dreht an einer Eigenschaft: Persistenz. Jede Container machine läuft in ihrer eigenen leichtgewichtigen VM und nutzt dasselbe OCI-Image-Format wie ein Container, etwa Alpine oder Ubuntu als Startpunkt. Anders als ein flüchtiger Anwendungs-Container behält sie ihren Zustand. Was man mit apt oder apk installiert, was man baut, was man konfiguriert, bleibt für die nächste Sitzung erhalten.

Der entscheidende Teil ist die Integration in macOS, und die geht weiter, als es zunächst klingt:

• Automatisches User-Mapping. Eine Container machine spiegelt den macOS-Benutzernamen und das aktuelle Arbeitsverzeichnis. whoami in der Container machine liefert denselben Namen wie auf dem Mac, pwd denselben Pfad.
• Geteiltes Dateisystem. Projektdateien sind ohne Kopieren oder Sync verfügbar. In Apples Demo wird eine Vapor-Webanwendung in Xcode auf dem Mac bearbeitet, in der Container machine unter Linux gebaut und ausgeführt, und das Ergebnis in Safari auf dem Mac geöffnet. Eine in Icon Composer geänderte Icon-Datei taucht nach einem Reload im Browser auf, ohne dass irgendetwas in die Linux-Umgebung kopiert wurde.¹
• Eintritt von überall. Aus jedem Terminal heraus lässt sich die Linux-Umgebung betreten, mit container machine run ohne weitere Argumente startet eine interaktive Shell.

Apples eigene Formel dafür lautet: „fast and lightweight, like a container, and persistent like a virtual machine."¹ Wer Windows kennt, hat das Muster sofort. Das ist Apples Variante von WSL, dem Windows Subsystem for Linux, das auf der anderen Plattform längst zum festen Bestandteil des Entwickleralltags geworden ist. The Register zieht in seiner Einordnung genau diese Parallele und nennt es ein „WSL-ish thing" für Mac-Entwickler.⁷

Warum das Docker weh tut

Bis hierher klingt das nach einem netten Entwicklerwerkzeug. Der Angriff auf Docker liegt nicht in der Technik allein, sondern in der Stelle, an der Apple ansetzt.

Docker Desktop ist seit der Lizenzänderung kommerziell heikel. Unternehmen mit mehr als 250 Mitarbeitern oder über 10 Millionen US-Dollar Jahresumsatz müssen zahlen. Docker Business kostet 24 US-Dollar pro Nutzer und Monat. Für ein Team von 50 Entwicklern sind das rund 12.600 US-Dollar im Jahr, bei 200 Entwicklern etwa 50.400 US-Dollar.⁸ Das ist eine Position, die in jeder Beschaffungsabteilung auffällt.

Dazu kommt der Ruf als Ressourcenfresser. Die ständig laufende VM, mehrere Gigabyte RAM im Leerlauf, CPU-Spitzen beim Image-Build, und auf dem Mac die seit Jahren bekannte Schwäche bei der Dateisystem-Performance von Volume-Mounts. Genau diese drei Schmerzpunkte, Lizenzkosten, Ressourcenhunger und Mac-Dateisystem, sind die Gründe, aus denen Teams längst zu Alternativen abwandern.

Apple greift damit nicht ins Leere, sondern in einen bereits umkämpften Markt. OrbStack gilt vielen als schnellste und sauberste Docker-Desktop-Alternative auf dem Mac, Podman ist daemon-los und rootless, Colima und Lima sind quelloffen und etabliert, Rancher Desktop ist unter Apache 2.0 ohne Mitarbeiterschwelle frei.⁹ In diese Liste schreibt Apple jetzt einen Namen, der einen Vorteil hat, den keiner der anderen bieten kann: Er kommt vom Hersteller des Betriebssystems und der Hardware und spricht direkt mit dem Virtualization.framework, ohne Emulationsschicht.

Die Lücken

Apple liefert kein fertiges Produkt, sondern eine Architektur im Aufbau, und die Lücken sind real.

Nur macOS 26, nur Apple Silicon. Wer auf macOS 15 bleibt oder Intel-Macs einsetzt, ist außen vor oder bekommt eingeschränkte Funktionalität. Apple adressiert ausdrücklich nur den aktuellsten Stand.²

Netzwerk zwischen Containern. Auf macOS 15 ist die Container-zu-Container-Kommunikation nicht voll unterstützt, ein Problem für jede Multi-Service-Architektur aus Web-Server plus Datenbank. Erst macOS 26 glättet das.³ Wer also klassische Compose-Stacks lokal fährt, stößt früh an eine Grenze.

Kein Docker Compose, kein Swarm. Es gibt keine bestätigte Compose-Entsprechung und keine Orchestrierung im Docker-Sinn. Für Einzelcontainer und einzelne Linux-Umgebungen reicht das, für orchestrierte lokale Stacks nicht.

Speicher lässt sich nicht zurückgeben. The Register nennt als gravierendsten Mangel, dass der Speicher einer Container machine standardmäßig auf die Hälfte des System-RAM gesetzt ist und „cannot be released back to the host", ohne die VM neu zu starten.⁷ Auf einem Notebook mit 16 GB ist das spürbar.

Keine GUI-Apps, schlechte Auffindbarkeit. Grafische Linux-Anwendungen werden nicht unterstützt, für X11-Forwarding muss man XQuartz separat installieren. Und das Projekt liegt, so The Register, „tucked away on GitHub rather than being presented as part of macOS". Im Hands-on der Redaktion schlug außerdem das Swift-Debugging fehl, während .NET-Debugging funktionierte. Das Fazit dort: Apple „has work to do both on features and documentation".⁷

Angriff auf Docker oder auf Docker Desktop?

Hier lohnt die Präzision, die der „Bye Docker"-Schlagzeile fehlt.

Docker ist nicht eine Sache, sondern drei. Erstens ein Image-Format und ein Ökosystem aus Registries, also die Art, wie Software paketiert und verteilt wird. Zweitens eine CLI und ein Daemon, die Container lokal bauen und ausführen. Drittens Docker Desktop, das kommerzielle Mac- und Windows-Produkt, das diese Laufzeit bequem auf den Entwicklerrechner bringt.

Apple greift gezielt die dritte Schicht an und übernimmt die erste. Das OCI-Format bleibt, die Registries bleiben, Images aus der Docker-Welt laufen weiter. Was Apple ersetzt, ist die lokale Laufzeit auf dem Mac, also genau der Teil, für den Docker Geld verlangt und für den es technisch am meisten kritisiert wird. Das ist kein Angriff auf Docker als Standard, sondern auf Docker Desktop als Produkt.

Genau deshalb wäre „Apple tötet Docker" die falsche Schlussfolgerung. Container machine konkurriert in Wahrheit weniger mit dem Docker-Daemon als mit Lima, Colima, OrbStack und mit WSL als Vorbild. Es ist Apples Versuch, den lokalen Linux-Workflow auf dem Mac so nativ zu machen, dass die externe Abhängigkeit überflüssig wird. Für den einzelnen Entwickler mit zwei, drei Containern und dem Wunsch nach einer dauerhaften Linux-Umgebung ist das jetzt schon attraktiv. Für Teams mit orchestrierten Multi-Service-Stacks, Compose-Dateien und gemischter Hardware bleibt Docker bis auf Weiteres gesetzt.

Treffender als eine Kampfansage ist deshalb das Bild einer Verschiebung mit Ansage. Apple baut die Schicht, die am teuersten und am unbeliebtesten war, ins Betriebssystem ein, lässt den Rest des Ökosystems unangetastet und wartet ab. Wenn macOS 26 die Netzwerk-Lücke schließt und eine Compose-Entsprechung nachkommt, wird aus dem leisen Angriff ein lauter. Bis dahin ist Container machine das, was Apple selten so offen baut: ein Entwicklerwerkzeug, das genau einen Konkurrenten im Blick hat, ohne ihn beim Namen zu nennen.