- Eine native macOS-App, mit der sich Linux-Container auf Apple-Silicon-Macs mit Apples Container-Plattform ausführen und verwalten lassen, und die ohne Docker Desktop genutzt werden kann
- Kommuniziert per XPC direkt mit Apples Open-Source-container-Daemon und verwendet damit denselben Pfad wie die CLI; nutzt weder Electron noch Webviews noch einen eigenen Hintergrund-Agenten
- Starten und Stoppen von Containern, Log-Streaming, Terminalzugriff, Dateibrowser, Dockerfile-Builds und Compose-Import werden in einer einzigen App erledigt
- Wird als kostenlose Open-Source-App unter MIT-Lizenz angeboten, ist mit Apple Developer ID signiert und notariell beglaubigt; benötigt wird ein Apple-Silicon-Mac mit macOS 15 oder neuer
- Anders als Docker Desktop werden leichtgewichtige VMs pro Container verwendet; wenn keine laufenden Container vorhanden sind, liegt der Hintergrunddienst der Plattform im Leerlauf bei etwa 25 MB
Zweck und Laufzeitumgebung von Davit
- Davit ist eine vollständig native macOS-App für Apples Container-Plattform
- Führt Linux-Container auf Apple Silicon aus, ohne dass Docker Desktop erforderlich ist
- Ist kostenlose Open Source und wird unter der MIT-Lizenz bereitgestellt
- Die App ist mit Apple Developer ID signiert und notariell beglaubigt
- Voraussetzung ist ein Apple-Silicon-Mac mit macOS 15 oder neuer
- Die Installation ist über die Releases oder per Homebrew möglich
brew install wouterdebie/tap/davit
Direkte Kommunikation mit dem Apple-container-Daemon
- Davit kommuniziert per XPC direkt mit Apples Open-Source-Daemon container
- Dies ist derselbe Kommunikationspfad, den auch die
container-CLI verwendet - Es werden weder Electron noch Webviews noch ein eigener Hintergrund-Agent eingesetzt
Funktionen zur Container-Verwaltung
- Das Dashboard zeigt Services aller laufenden Container, Festplattennutzung und CPU in Echtzeit
- In der Container-Liste lässt sich der Status pro Zeile einsehen und direkt steuern
- Starten, stoppen, neu starten, löschen
- Echtzeit-CPU
- Arbeitsspeicher
- IP
- Die Ansicht pro Container bietet zusätzlich Funktionen zur Einschätzung des Laufzeitstatus
- Streaming-Logs mit Follow- und Boot-Modus
- Statusdiagramme in Echtzeit
- Einsicht in die rohe Konfiguration
- Für laufende Container kann direkt per nativer API ein Terminal geöffnet werden
- Eine interaktive Shell kann in Terminal oder iTerm geöffnet werden
- Keine CLI erforderlich
Bearbeitung unveränderlicher Container und Dateizugriff
- Da Container unveränderlich sind, kann Davit auf Basis der bestehenden Konfiguration einen neuen Container vorausgefüllt neu erstellen
- In die neue Container-Konfiguration wird die bestehende Konfiguration übernommen, ausgenommen EntryPoint und env des Images
- Der Ablauf ist auf schnelle Änderungen an Ports, Umgebungsvariablen, Mounts und Ressourcen ausgelegt
- Das Dateisystem laufender Container kann innerhalb der App durchsucht werden
- Zwischen Ordnern wechseln
- Dateien auf den Mac herunterladen
- Dateien hochladen
- Dateien löschen
- Dateivorgänge werden über native APIs verarbeitet; der Befehl
docker cpist nicht nötig
Compose-Import und Dockerfile-Builds
- Davit kann
docker-compose.ymlöffnen und vorab anzeigen, welche Ressourcen erstellt werden- Services in Abhängigkeitsreihenfolge
- Volumes
- Netzwerke
- Gleichwertige CLI-Befehle pro Service
- Warnungen zu nicht unterstützten Einträgen
- Da Apples Plattform kein natives Compose hat, orchestriert Davit den Stack selbst
- Der Compose-Import zielt auf eine unterstützte Teilmenge
- Unterstützt: image, ports, environment, named/bind volumes, networks, resource limits, command, user, working_dir
- Beispiele für Warnungen:
restart:,healthcheck:,build:
- Dockerfile-Builds sind unter Images → Build Image möglich
- Kontextordner und Dockerfile auswählen
- Tags und Build-Args festlegen
- Davit startet Apples auf BuildKit basierenden Builder direkt und bei Bedarf automatisch
- Derzeit gibt es auch Plattformbeschränkungen
- Dockerfiles über 16 KiB werden abgelehnt
- Dies ist mit einem Upstream-apple/container bug verknüpft
- Der Build-Kontext darf nicht unter
/tmpliegen
Images, Volumes, Netzwerke und Registries
- Davit unterstützt imagebezogene Aufgaben
- Pull mit Fortschrittsanzeige
- Container aus Images starten
- Taggen
- Prune
- Auch Volume- und Netzwerkfunktionen werden bereitgestellt
- Volumes mit angegebener Größe erstellen
- Eigene Subnetze erstellen
- Vor dem Löschen prüfen, welche Einträge in Verwendung sind
- Registry-Login erfolgt unter Settings → Registries
- Docker Hub
- ghcr.io
- quay.io
- Beliebige OCI-Registry
- Zugangsdaten werden vor dem Speichern bei der Registry validiert
- Validierte Zugangsdaten werden im macOS-Login-Schlüsselbund gespeichert und mit der
container-CLI geteilt - Docker Hub verlangt statt eines Passworts die Verwendung eines Access Tokens
Plattform-Einstellungen und automatische Installation
- Davit erlaubt das Bearbeiten der Plattform-Einstellungen direkt in der App
- Standard-CPU/-Speicher für neue Container
- Registries
- DNS
- Builder-Ressourcen
- Die Einstellungen werden vom plattformeigenen Konfigurations-Loader validiert und als sauberes TOML-Override gespeichert
- Wenn die Apple-Container-Plattform nicht installiert ist, lädt Davit Apples signiertes Installationsprogramm herunter, prüft es und installiert es in der Benutzer-Library
- Für die Installation sind keine Administratorrechte erforderlich
- Bei Bedarf kann auch die
container-CLI zur Shell hinzugefügt werden
Implementierung der App und Einstieg
- Davit ist vollständig in SwiftUI umgesetzt
- Bietet Schnellaktionen in der Menüleiste
- Das Dock-Symbol kann nur dann angezeigt werden, wenn der Nutzer es möchte
- Für das Rendern von Echtzeitdiagrammen wird kein Browser gestartet
- Ein beispielhafter Einstieg sieht so aus
- Über Releases installieren oder per Homebrew installieren
- Falls beim ersten Start keine Plattform vorhanden ist, installiert Davit sie
- Unter Images → Pull Image
nginxdemos/hellopullen - Aus dem Image starten oder Containers → Run Container verwenden
- Host
8088auf Container-80mappen - In der Zeile Ports des Containers auf Open in Browser klicken oder
localhost:8088aufrufen - Im laufenden Container CPU, Speicher, Festplatte, Logs, Dateien, Terminal sowie die Funktion Edit & Recreate erkunden
Unterschiede zu Docker Desktop und OrbStack
- Davit verwendet Apples Engine
- Jeder Container läuft in seiner eigenen leichtgewichtigen VM auf Basis des Apple Virtualization Framework
- Verfügt über eine eigene IP-Adresse pro Container
- Für Apple Silicon optimiert
- Verwendet OCI-Images
- Pulls von Docker Hub, ghcr.io, quay.io oder beliebigen Registries sind möglich
- Auch private Images können per Registry-Login genutzt werden
- Linkt Apples Client-Bibliotheken und kommuniziert direkt per XPC
- Kein Socket-Shim
- Keine Lizenzvereinbarung
- Kein Account
- Das App-Bundle ist 17 MB groß
- Kein Electron
- Keine mitgelieferten VM-Images
- Kein eigener Hintergrunddienst
- Der Ansatz unterscheidet sich von OrbStack
- OrbStack ist eine kommerzielle App mit eigener Docker-kompatibler Virtualisierungsschicht
- Davit ist eine kostenlose Open-Source-Oberfläche auf Basis von Apples Container-Plattform
- Davit hat keine residenten Komponenten ohne Container, nutzt IPs pro Container und Bridge-Netzwerke und bietet stärkere Isolation zwischen Containern
- OrbStack ist besser bei Drop-in-Kompatibilität mit
docker-CLI/API und breiterer Tool-Unterstützung - Beide führen standardmäßige OCI-Images aus
Speicher, DNS und Sicherheit
- Die Speicherarchitektur vermeidet eine ständig laufende Linux-VM mit mehreren GiB
- Docker Desktop hält unabhängig von laufenden Containern eine große VM aktiv, während Apples Plattform pro Container eine leichtgewichtige VM bootet und sie beim Stoppen des Containers wieder beendet
- Wenn keine laufenden Container vorhanden sind, liegt der Hintergrunddienst der Plattform im Leerlauf bei etwa 25 MB
- Davit selbst ist eine native SwiftUI-App statt einer Electron-App; die Speichernutzung besteht überwiegend aus gemeinsam genutztem Speicher von macOS-Frameworks
- Für den Zugriff vom Mac über Containernamen kann die lokale DNS-Domain der Plattform genutzt werden
sudo container system dns create testeinmal ausführen oder eine eigene Domain verwenden- Unter Settings → Platform → DNS als Standard-Domain festlegen
- Der Container
webantwortet auf dem Mac unterweb.test
- Alle Container haben eine eigene IP, die im Abschnitt Network angezeigt wird
- Wenn Avahi im Gast läuft, kann ein
.local-mDNS-Alias gesendet werden - Jede Release ist mit Apple Developer ID signiert und notariell beglaubigt und lässt sich ohne Gatekeeper-Warnung öffnen
- Die App ist Open Source unter MIT-Lizenz und kann direkt gelesen oder gebaut werden
- Davit kommuniziert nur mit dem lokalen container-Daemon und zur Prüfung von GitHub-Updates
2 Kommentare
Die Verwaltung über die Kommandozeile war lästig, daher freue ich mich, dass es das jetzt gibt ^^ In letzter Zeit nutze ich allerdings hauptsächlich Orbstack.
Meinungen auf Hacker News
Meine beste Strategie im KI-Zeitalter ist: nichts tun
Ich hatte eine ähnliche Idee und dachte, man könnte sie per Vibe Coding bauen, ging aber davon aus, dass jemand anderes mehr Interesse daran haben und sie zuerst umsetzen würde – und genau so kam es
Die App sieht gut aus, und ich freue mich darauf, sie auszuprobieren
Als kostenlose Idee: Ich würde Agenten gern in einer virtuellen Maschine einsperren und ihnen von außerhalb der VM über ein Harness Anweisungen schicken, um die darin installierten Agenten zu steuern. Idealerweise sollte auf dem Host nichts wie Codex/Claude installiert sein
Noch besser wäre es, in der virtuellen Maschine mehrere Benutzerkonten anzulegen und pro Benutzer Dateisystem- und Netzwerk-Policies einzuschränken. Dann hätten Entwicklungsagenten, QA-Agenten usw. jeweils eine andere Sicht auf ihre Aufgaben, und das könnte eine starke Basisschicht für weitere Automatisierung werden
Natürlich müsste man diverse Ressourcen wie DBs, Queues und externe Volumes an die virtuelle Maschine „anhängen“ können, damit Agenten sie rechtebasiert nutzen können
https://GitHub.com/instavm/coderunner
Der Transparenz halber: Ich habe dort ein paar PRs eingereicht
https://github.com/webcoyote/sandvault
Irgendwann Ende 20 oder Anfang 30 habe ich fast komplett aufgehört, in meiner Freizeit zu entwickeln, weil mir der Spaß am Coden selbst völlig abhandengekommen war. Eigentlich mochte ich es ohnehin nie so sehr; ich war nur wirklich schlecht darin einzuschätzen, ob etwas meine Zeit wert ist oder nicht
Wenn mir ein Programm oder Skript einfiel, das nett zu haben wäre, war es meistens wie in der xkcd-Tabelle zur Amortisationszeit: Wie lange darf man an einem Programm bauen, um ein paar Minuten pro Woche zu sparen? Meistens „lohnte sich der Aufwand im Verhältnis zur Belohnung nicht“. Oder es war etwas, das nicht wirklich nötig war, aber interessant oder unterhaltsam gewesen wäre – nur hätte die Umsetzung unzählige Stunden gekostet und war es damit überhaupt nicht wert
Wenn jemand etwas gebaut und veröffentlicht hat, das ich wollte, war das schön; wenn nicht, dann eben nicht
Die große Veränderung durch LLMs ist, dass man kleine Skripte und Ähnliches jetzt in wenigen Minuten und für ein paar Cent bis ein paar Dollar erzeugen lassen kann. Ich hole gerade extrem nischige Ideen wieder hervor, die lange herumlagen
Dinge, bei denen früher schon das Durchforsten einer unbekannten API und ihrer Dokumentation mehrere Wochenenden verschlungen hätte, gehen jetzt in 30 Minuten – oder ich kann zumindest in ein paar Minuten statt in ein paar Stunden beurteilen, ob es nicht funktioniert oder so nervig ist, dass ich es für immer verwerfen sollte
Ich lasse gern mittelgroße bis große offene Modelle laufen, traue ihnen aber nicht zu, dass sie nicht aus dem Ruder laufen; deshalb habe ich es gebaut und werde es demnächst teilen
Es scheint mir so simpel wie: Claude in einer virtuellen Maschine installieren und per SSH-Terminal darauf zugreifen. Wenn man eine GUI braucht, bekommt man mit der Remote-SSH-Erweiterung von VSCode auch Dinge wie eine Dateibrowser-UI
Vermutlich kann man auch Claude oder andere Chat-Erweiterungen für VSCode in der virtuellen Maschine installieren
Was an diesem Projekt selbst mehr auffällt, ist, dass sich ein Phänomen sichtbar beschleunigt hat, das viele – besonders im letzten Jahr oder so – vorhersehen konnten. Menschen können ihre eigene Version derselben Idee jetzt viel schneller als früher bauen
Nach etwa 10 Minuten Suche fand ich mehrere ähnliche Swift-Projekte, die meisten davon erst wenige Wochen oder Monate alt
https://github.com/tdeverx/contained-app
https://github.com/nico81/iContainer
https://github.com/wouterdebie/davit
https://github.com/Augani/dory
https://github.com/tofa84/berth
https://github.com/erdaltoprak/ContainerUtility
https://github.com/andrew-waters/orchard
Wenn man Projekte mit weniger GitHub-Sternen, reine Kommandozeilen-Tools und Nicht-Swift-Projekte mitzählt, gab es noch mehr, aber der Punkt ist dieser:
Menschen werden zunehmend in der Lage sein, ihre eigene Version der Software zu bauen, die sie haben wollen. Dadurch sinkt der Wert von Software, die andere gebaut haben. Das Zeitalter hyperpersonalisierter Software kommt
Früher konnte man den Aufwand, der in so etwas geflossen ist, anhand der Qualität der Website oder einiger oberflächlicher Faktoren abschätzen. Heute erledigt ein LLM solche Dinge leicht
Ähnlich war im Rückblick einer der größten Effekte von Kickstarter, dass sich dreiminütige Pitch-Videos aggressiv weiterentwickelt und verfeinert haben
Ob das tatsächlich zu tief durchdachten Implementierungen, Roadmaps und echter Umsetzungsstärke führt, weiß ich nicht
Wirkt wie eine wirklich solide App. Sie ist 17 MB groß, und mir gefällt, dass sie die ContainerAPIClient-Bibliothek direkt nutzt
28 Commits in 3 Tagen, 5.015 Zeilen Swift, und jeder Commit ist mit „Co-Authored-By: Claude Fable 5“ versehen
Schön ist auch, dass sie signiert und notarisiert ist. Nach der Installation hat sie beim ersten Start die benötigten Container-Plattformkomponenten heruntergeladen
Als Vorschlag: Fügt der Website ein Einstiegstutorial hinzu, empfiehlt ein Image zum Ausprobieren und zeigt mit Screenshots oder einem stummen Video, wie man dieses Image ausführt und was man damit machen kann
Der Dialog zum Erstellen von Images schlägt „nginx:latest“ vor, aber als Einstiegsdemo ist das nicht besonders gut
nginx:latest zeigt zwar, dass die Verkabelung funktioniert, aber nicht wirklich, wo sich Apple Containers anders anfühlt als Docker Desktop oder OrbStack
Ein Beispiel mit einer kleinen App, Volumes, Port-Mapping und einer einfachen Rebuild-Schleife würde den Nutzen deutlich leichter sichtbar machen
Ha! Wir haben offenbar dasselbe gebaut: https://container-ui.fly.dev/
Jetzt denke ich, ich hätte die vielen Tokens lieber nicht verbrennen sollen
Sieht sauber aus. Am Ende bauen wir wohl alle dasselbe ><
Ich nutze OrbStack seit fast zwei Jahren sehr gern
Die Integration ist gut, es ist schnell und docker-befehls-kompatibel, daher war es mir das Geld wert
Trotzdem werde ich das hier auch einmal ausprobieren
Die Stärke von OrbStack ist, dass alle Container in einer einzigen Linux-VM laufen und auf beiden Seiten der VM-Grenze viele Optimierungen vorgenommen werden. Dazu gehört auch die Nutzung von Sparse-Image-Dateien, die auf der macOS-Seite viel Speicherplatz sparen
Wenn man unter macOS mehr als 4–5 Container laufen lässt, machen sich die Performance- und Ressourceneinsparungen von OrbStack schnell stark bemerkbar
Wirklich gut. Das Herunterladen der Runtime und das Ausführen von nginx:latest haben perfekt funktioniert
Wenn man auf GitHub nach unten scrollt und Claude als Contributor sieht, scheint das langsam zu einem Signal dafür zu werden, dass die App gut sein wird. Also im Sinne von nativ wirkend und nicht Electron
Ich wünschte, Apple würde Apple Containers docker-API-Kompatibilität hinzufügen
Dinge wie Port-Forwarding oder Host-Volumes gibt es nicht. Tatsächlich liegt der Fokus darauf, buildkit auf dem Mac laufen zu lassen
Allerdings ist es vollständig mit docker CLI und buildx integriert
https://github.com/cpuguy83/crucible
Die Funktionen gefallen mir, und auch, dass es eine kleine native SwiftUI-App ist
Ich habe kürzlich einen Artikel [1] über den Einsatz von Apple-Containern für agentenbasiertes Coding geschrieben und ihn gerade aktualisiert, um Davit zu erwähnen. Für persönliche Projekte auf meinen beiden Macs zu Hause bevorzuge ich Apple-Container inzwischen deutlich gegenüber Docker
[1] https://open.substack.com/pub/marklwatson/p/running-opencode...
Wie schlägt sich das im Vergleich zu OrbStack? Bieten Apple Containers etwas, das man in der Developer Experience spürbar merkt? Nach meinem Nutzungsprofil fühlt sich die OrbStack-Implementierung bereits blitzschnell an
Ich habe vor ein paar Tagen eine ähnliche Version gepostet, die ich gebaut habe, aber sie hat kaum Resonanz bekommen
Falls es jemanden interessiert: Es ist eine Menüleisten-App mit Unterstützung für Container, Maschinen und Registries
https://news.ycombinator.com/item?id=48789503
https://github.com/erdaltoprak/ContainerUtility