Container Machines: Eine persistente Linux-Umgebung auf dem Mac

Apples container-Tool hat während der WWDC-Woche die Version 1.0 erreicht, und die zentrale Funktion schließt eine Lücke, um die Mac-Entwickler jahrelang herumarbeiten mussten: container machine, eine persistente Linux-Umgebung, die sich wie ein Teil von macOS verhält.² Die WWDC-Session, die sie vorstellt, bringt das Konzept in einem Satz auf den Punkt: „A Container machine is fast and lightweight, like a container, and persistent like a virtual machine.”¹ Ihre Repositorys und Dotfiles sind auf beiden Seiten verfügbar, der Login-Benutzer entspricht Ihrem Mac-Account, und die Machine behält ihr Dateisystem zwischen den Sitzungen, sodass die Linux-Toolchain, die Sie am Dienstag eingerichtet haben, am Freitag immer noch vorhanden ist.³

Session 389, „Discover container machines.”

TL;DR

• container machine wird mit container 1.0.0 ausgeliefert, das während der WWDC-Woche auf GitHub veröffentlicht wurde. Es bietet „long-lived Linux environments with tight host integration” auf Basis des Containerization-Frameworks, das Apple auf der WWDC 2025 als Open Source veröffentlicht hat.²
• Während Container „nach einer Anwendung modelliert” sind, ist eine container machine „nach einer Linux-Umgebung modelliert”: Sie führt das eigene Init-System des Images aus, persistiert Dateisystemänderungen und wird aus standardmäßigen OCI-Images erstellt.³
• Die Host-Integration ist das Unterscheidungsmerkmal. Der Linux-Login-Benutzer entspricht Ihrem Mac-Account mit passwortlosem sudo, und Ihr Home-Verzeichnis wird in die Machine eingebunden,⁴ und eine interaktive Shell setzt Sie in genau dasselbe Arbeitsverzeichnis, aus dem Sie unter macOS gekommen sind.¹
• Der vollständige Satz an Unterbefehlen lautet create, run, list, inspect, set, set-default, logs, stop und delete, mit m als Kurzalias.⁴
• Das 1.0-Release bringt außerdem eine Breaking Change mit sich, die Sie vor dem Upgrade kennen sollten: Eine TOML-Konfigurationsdatei unter ~/.config/container/config.toml ersetzt die alten, über UserDefaults gestützten Systemeigenschaften, und die container system property-Unterbefehle sind entfallen.²

Eine Linux-Umgebung, keine Anwendungs-Sandbox

Apples Dokumentation zieht die Grenze präzise: „Containers are typically modeled after an application. A container machine is modeled after a Linux environment.”³ Der Unterschied zeigt sich in drei Verhaltensweisen. Eine container machine führt das eigene Init-System des Images aus, etwa systemd oder openrc, sodass Sie langlaufende Dienste registrieren und Ihre Anwendung unter einer echten Prozessüberwachung testen können: systemctl start postgresql funktioniert so, wie es auf einem Linux-Rechner tut.³ Sie persistiert Änderungen, sodass installierte Tools sich mit der Zeit ansammeln, anstatt mit dem Prozess zu verschwinden.¹ Und sie bootet von denselben OCI-Images, die auch Container verwenden, sodass ein Image, das Sie mit container build erstellen, zugleich als Ausgangspunkt für eine Machine dient.¹

Der Pull Request, der die Funktion eingebracht hat, formuliert die Motivation unmissverständlich: container führt jede Workload in einer flüchtigen VM aus, sodass es vor 1.0 keine eingebaute Möglichkeit gab, eine persistente Linux-Umgebung vorzuhalten, in die man sich einloggen und in der man arbeiten konnte.⁴ Darunter erhält jede container machine weiterhin die Containerization-Behandlung: ihre eigene leichtgewichtige virtuelle Maschine mit VM-basierter Isolation und den Startzeiten im Subsekundenbereich, um die herum das Framework gebaut wurde.¹

Die Session formuliert die Designziele in Workflow-Begriffen: Der Wechsel zwischen macOS und Linux sollte einfach sein, Umgebungen sollten schnell zu erstellen sein, und „quick creation allows multiple projects to have their own, dedicated environment, without the worry of conflicting dependencies or toolchains.”¹ Eine Machine pro Ziel-Distribution ist ein beabsichtigtes Muster, und jede Machine sieht dasselbe Home-Verzeichnis und dieselben Dotfiles von Ihrem Mac.³

Der Ablauf: auf dem Mac bearbeiten, in Linux bauen

Die Demo der Session ist ein Vapor-Webserver, und der Workflow, den sie durchspielt, ist genau der springende Punkt.¹ Das Projekt wird in Xcode unter macOS bearbeitet. Der Build und die Ausführung erfolgen in einer container machine, in der die Swift-Toolchain installiert ist. Safari auf dem Mac lädt den laufenden Server über IP-Adresse und Port. Als der Vortragende ein App-Icon aus Icon Composer auf dem Mac neu exportiert und die Datei überschreibt, zeigt ein Browser-Refresh das neue Asset ohne Kopierschritt, weil die Machine und der Mac dieselben Dateien teilen.¹

Apples Dokumentation verallgemeinert das Muster: Ihr Repository liegt in $HOME unter macOS und wird in die Machine eingebunden, sodass macOS-native Werkzeuge (Profiler, Browser, GUI-Debugger) dieselben Dateien sehen wie die Linux-Umgebung. Wie es die Dokumentation ausdrückt, gibt es keinen Kopierschritt zwischen „I built it” und „I am inspecting it.”³

Die Host-Integration reicht tiefer als ein gemeinsames Mount. Die Machine erstellt automatisch einen Linux-Benutzer, der Ihrem Mac-Benutzernamen entspricht, gewährt ihm passwortloses sudo und spiegelt Ihr aktuelles Arbeitsverzeichnis, sodass whoami und pwd innerhalb und außerhalb dasselbe antworten.¹ Der einzige Befehl, der seine Antwort ändert, ist uname: Darwin auf dem Mac, Linux in der Machine.¹

Eine Reibungsstelle gleich am ersten Tag sollten Sie kennen, bevor Sie auf sie stoßen: Eine container machine hat ein isoliertes Netzwerk, und die Session stellt klar, dass ein Server in ihr auf der externen Schnittstelle lauschen muss, bevor ein Browser auf dem Mac ihn erreichen kann.¹ Die Demo handhabt das so, wie Sie es tun werden: container machine list zeigt die IP-Adresse jeder Machine neben ihrem Namen und ihren Ressourcen an, die Serverkonfiguration bindet an diese Adresse, und Safari erreicht die App unter der IP und dem Port der Machine.¹ Planen Sie den IP-Adressschritt in jedem Workflow ein, der Traffic aus der Machine heraus bedient.

Die Befehle

Der Schnellstart umfasst vier Zeilen:³

container machine create alpine:latest --name dev
container machine run -n dev whoami       # your host username, not root
container machine run -n dev pwd          # your Mac home directory, mounted in
container machine run -n dev              # interactive shell

container machine run erfüllt eine Doppelfunktion: Mit einem Befehl führt es diesen einmal aus und beendet sich, ohne einen öffnet es eine interaktive Shell, und falls die Machine gestoppt ist, bootet es sie zuerst.³ Eine Standard-Machine entfernt das -n-Flag aus jedem Aufruf:

container machine set-default dev
container machine run                     # operates on dev

Die Verwaltung erfolgt über die vertrauten Verben: ls, inspect, logs, stop und rm, wobei das Löschen einer Machine auch ihren persistenten Speicher entfernt.³ Ressourcen lassen sich nach der Erstellung mit container machine set -n dev cpus=4 memory=8G anpassen, wirksam beim nächsten Stoppen und Starten; der Arbeitsspeicher ist standardmäßig auf die Hälfte des Host-Speichers gesetzt, und das Home-Mount kann rw (Standard), ro oder none sein.³ Jeder Befehl akzeptiert außerdem m als Alias, sodass m run und m ls funktionieren.⁴

Bringen Sie Ihr eigenes Machine-Image mit

Jedes Linux-Image, das /sbin/init enthält, funktioniert als container machine.³ Apples Dokumentation liefert ein ausgearbeitetes Dockerfile mit, das ubuntu:24.04 mit systemd, OpenSSH und gängigen Kommandozeilenwerkzeugen in ein Machine-Image verwandelt und anschließend die systemd-Units maskiert, die in einer leichtgewichtigen VM keinen Sinn ergeben.³ Sie bauen es mit container build und übergeben den Tag an container machine create.

Die Provisionierung hat eine Ausweichmöglichkeit. Standardmäßig führt container beim ersten Booten ein eingebautes Setup-Skript aus, um den passenden Benutzer zu erstellen. Eine ausführbare Datei unter /etc/machine/create-user.sh im Image ersetzt dieses Skript; sie läuft einmal, als Root, beim ersten Booten, mit gesetzten Variablen CONTAINER_USER, CONTAINER_UID, CONTAINER_GID, CONTAINER_HOME und CONTAINER_MACHINE_ID, sodass eine Organisation ihre eigene Benutzereinrichtung in ein gemeinsames Basis-Image kodieren kann.³

Der Rest von 1.0, einschließlich der Breaking Change

Die Machine-Funktion ist das Aushängeschild des Releases, aber 1.0 bringt Änderungen mit sich, die bestehende Benutzer betreffen.²

Die folgenreiche betrifft die Konfiguration. Eine TOML-Datei ersetzt die über UserDefaults gestützten Systemeigenschaften, und die Unterbefehle container system property get und set werden entfernt.² Der Dienst liest beim Start ~/.config/container/config.toml mit der Vorrangregel „erster Treffer gewinnt” (Ihre Benutzerdatei, dann eine optionale, mit der Paketinstallation ausgelieferte Datei, dann fest kodierte Standardwerte), und Änderungen erfordern einen Neustart des Dienstes, um wirksam zu werden.⁶

Die Komfortverbesserungen: ein container cp-Befehl zum Kopieren von Dateien, eine --stop-signal-Option für container run und eine bereinigte strukturierte Ausgabe (JSON, YAML, TOML) für die Befehle ls und inspect über Container, Images, Netzwerke und Volumes hinweg.² Das Networking erhält eine Korrektur, die XPC-Verbindungen als Leases nutzt, um Lecks von IP-Adressen zu unterbinden.² Die Kompatibilität mit den XPC-APIs der Version 0 wird entfernt, mit einer versionierten API, die für ein späteres Release zugesagt ist.²

Die Anforderungen bleiben gegenüber der 0.x-Reihe stabil: ein Mac mit Apple silicon, auf dem macOS 26 läuft. Die Maintainer geben an, dass sie sich in der Regel nicht mit Problemen befassen, die sich nicht unter macOS 26 reproduzieren lassen.⁵

Warum Agent-Workflows das interessieren sollte

Eine Einschätzung aus meiner Perspektive, keine Aussage von Apple: Eine container machine hat genau die Gestalt einer Umgebung, die Coding-Agents wollen. Agents, die auf einem Mac laufen, brauchen einen Ort, an dem sie Builds ausführen, Server betreiben und Abhängigkeiten installieren können, ohne den Host anzufassen: schnell zu erstellen, durch eine echte VM-Grenze isoliert, persistent genug, dass eine in einer Sitzung installierte Toolchain bis zur nächsten erhalten bleibt. Bislang waren die Mac-Antworten VMs im Stil von Docker Desktop (schwergewichtig, eine große gemeinsame Umgebung) oder flüchtige Container (isoliert, aber vergesslich). Eine Machine pro Projekt, erstellt aus einem versionierten OCI-Image, mit eingebundenem Repository und passwortlosem sudo darin, passt zu der Art, wie Agent-Sandboxes auf Linux-Hosts bereits funktionieren.

Dieselbe Eigenschaft dient auch der schlichten plattformübergreifenden Arbeit. Server-seitiges Swift ist der naheliegende Nutznießer: Die Demo der Session ist Vapor, und das Foundation Models Framework wird diesen Sommer Open Source mit Linux-Unterstützung, sodass die Testumgebung für „läuft mein Swift-Code unter Ubuntu” jetzt nur noch ein container machine create entfernt ist. Der Vergleich, der jedem in den Sinn kommt, der Windows verwendet hat, ist WSL, und die Richtung der Integration ist dieselbe: ein echter Linux-Kernel eine Shell entfernt, mit Ihren auf beiden Seiten sichtbaren Dateien. Apples Version kommt bereits mit einem image-basierten Workflow im Gepäck.

FAQ

Was ist eine container machine?

Eine container machine ist eine persistente Linux-Umgebung unter macOS, die ab Version 1.0.0 als Funktion von Apples Open-Source-Tool container ausgeliefert wird.² Sie läuft in ihrer eigenen leichtgewichtigen virtuellen Maschine über das Containerization-Framework, bootet aus standardmäßigen OCI-Images, führt das Init-System des Images aus und persistiert Dateisystemänderungen zwischen den Sitzungen.¹ Host-Integrationen binden Ihr Home-Verzeichnis darin ein, gleichen den Linux-Benutzer mit passwortlosem sudo an Ihren Mac-Account an und halten Ihr Arbeitsverzeichnis über die Grenze hinweg konsistent.⁴

Wie unterscheidet sie sich von einem regulären Container?

Apples Dokumentation bringt es in einer Zeile auf den Punkt: Container sind „modeled after an application”, eine container machine ist „modeled after a Linux environment.”³ Eine reguläre container run-Workload ist flüchtig und prozesszentriert. Eine Machine ist zustandsbehaftet, führt systemd oder openrc aus und ist dafür gedacht, im Laufe der Zeit immer wieder aufgesucht zu werden, wie eine VM mit der Erstellungsgeschwindigkeit eines Containers.¹

Was setzt sie voraus?

Einen Mac mit Apple silicon, auf dem macOS 26 läuft, dieselben Anforderungen wie beim container-Tool allgemein.⁵ Das Tool ist Open Source auf GitHub und in Swift geschrieben.⁵

Bricht das Upgrade auf 1.0 irgendetwas?

Eine Sache: Die Systemkonfiguration wechselt von über UserDefaults gestützten Eigenschaften zu einer TOML-Datei unter ~/.config/container/config.toml, und die Unterbefehle container system property get/set werden entfernt.² Die 1.0-Release-Notes verlinken ein Tutorial für die Migration.² Auch die Kompatibilität mit der XPC-API der Version 0 wird entfernt, was relevant ist, wenn Sie Clients gegen die API gebaut haben.²

Container Machines fügen sich in dieselbe Geschichte ein, die diese WWDC immer wieder erzählt hat: der Mac als ernsthafte Heimat für plattformübergreifende und agentische Entwicklung. Running Agentic AI on the Mac with MLX behandelt die Model-Serving-Hälfte dieser Geschichte, und What’s New in Swift (2026) behandelt die Spracharbeit, die Swift-on-Linux zu einem erstklassigen Ziel macht. Der vollständige Hub der Reihe ist die Apple Ecosystem Series.

Referenzen