Civo ist der Cloud-Anbieter, dem ich meine eigenen Produktions-Workloads anvertraue. Als ich einen schnelleren Weg brauchte, Cluster, S3-Buckets und Firewalls zu verwalten ohne im Browser-Dashboard zu wohnen, habe ich CivoCloudManager gebaut — eine native macOS-App, die direkt mit der Civo-API spricht. Dann habe ich sie kostenlos in den App Store gestellt und entschieden, den Rest öffentlich für die Civo-Community zu bauen.
Dieser Beitrag ist die Architektur-Aufschlüsselung und die Roadmap. Zwei Monate später läuft sie auf echten Schreibtischen.
Warum bauen, warum verschenken
Civos Web-Dashboard ist gut. Aber „gutes Web-Dashboard” ist immer noch ein Browser-Tab in einer See von Tabs, mit einem Refresh-Knopf und ohne Menubar-Status, und du kannst nicht zehn Cluster-Kontexte gleichzeitig im Blick behalten ohne den Verstand zu verlieren. Eine native App löst das — und die Civo-Community fragt seit Jahren in den Slack-Channels danach.
Ich hatte zwei Optionen: warten bis jemand sie baut, oder selbst bauen und nicht dafür kassieren. Sie zu verschenken macht sie zu einem Teil dessen, wie sich das Civo-Ökosystem anfühlen sollte. Es ist nebenbei auch das ehrlichste Portfolio-Stück, das ich Cloud-Platform-affinen Kunden zeigen kann.
Die App-Store-Distribution ist kostenlos; der Quellcode liegt auf GitHub unter einer Lizenz, die sagt: nutze es, forke es, lerne daraus.
Die Architektur — null Dependencies, reines SwiftUI
Die ganze App ist ein einziges Swift-Package, keine Drittanbieter-Bibliotheken. Das klingt nach Eitelkeit; ist es nicht. Es bedeutet: kleine Binary, winzige Security-Surface, kein Transitive-Dependency-Drift. Für eine App, deren einziger Job „mit zwei APIs sprechen” ist, brauchst du kein Framework.
Eine Schicht spricht mit Civo
Ein einziger CivoClient-Actor kapselt die Civo-HTTP-API. Das Token kommt aus dem macOS-Keychain — nie von Disk, nie geloggt. Jeder Request läuft mit Structured Concurrency: async let für die parallelen Aufrufe (Instanzen plus Cluster plus Buckets aus einem einzigen Screen-Load), keine Callbacks, keine Combine-Kette zum Debuggen.
Eine Schicht spricht mit Kubernetes
Die Kubernetes-Integration läuft direkt gegen die K8s-API — kein kubectl-Shellout, keine Helper-Binary. CivoCloudManager lädt die kubeconfig von Civo, parst sie und spricht ab dann die Kubernetes-API genauso wie jeder andere Client. Pod-Logs streamen über Websocket; Metriken kommen vom metrics-server wenn vorhanden, sind sauber leer wenn nicht. Acht Sprachen, alles SwiftUI-Strings, alles gebündelt.
Menubar-Modus, der seine Berechtigung verdient
Klick aufs Menubar-Icon und du siehst ein 480-px-Fenster mit dem zuletzt genutzten Cluster, Live-Pod-Metriken im Scroll, ein Inline-Log-Tail das du pinnen kannst. Kein Tab. Kein Refresh. Das ist der ganze Grund, warum die App existiert.
Build-in-Public-Prinzipien
Drei Selbstverpflichtungen, die ich einhalte:
Öffentliche Roadmap. Die nächsten Features stehen auf GitHub Issues mit groben Daten. Wenn etwas verrutscht, wird das Issue aktualisiert, nicht still verschoben. Wenn etwas früher als geplant geht, verlinkt der Commit das Issue.
Sichtbare Entscheidungen. Architektur-Änderungen — Observability einbauen, wie Credentials gespeichert werden, was bewusst weggelassen wird — bekommen eine kurze Notiz im decisions/-Ordner des Repos. Es geht nicht um Prozess-Theater; es geht darum, dass jemand, der das in einem Jahr forkt, sieht warum der Code so aussieht wie er aussieht.
Community-getriebene Priorisierung. Eine echte Frage im Civo-Community-Slack schlägt alles auf meiner spekulativen Roadmap. Das 2.0-Release hat alles umsortiert weil drei verschiedene User in der gleichen Woche denselben DNS-Schmerz gemeldet haben.
Was ich beim Ausliefern gelernt habe
Native macOS ist zurück. Die Leute wollen das. Die „alles ist jetzt Electron”-Ära endet, und eine 12-MB-Swift-App, die in 80 ms bootet, in einer Wüste aus 400-MB-Electron-Tools überrascht Leute im besten Sinne.
Civos API belohnt einen dünnen Client. Keine Middleware nötig. Rate-Limits sind großzügig, Response-Shapes sauber, das Bearer-Token-Modell unkompliziert. Wenn du etwas auf Civo aufbauen willst, kannst du das — und die API stellt sich dir nicht in den Weg.
Kostenlos plus gut ist eine Marketing-Strategie. Ich habe keine einzige Anzeige geschaltet. Die App hat organische Bewertungen weil Civo-Nutzer anderen Civo-Nutzern davon erzählen. Das ist die einzige Art Marketing, die für ein Tool wie dieses skaliert.
Was als nächstes auf der öffentlichen Roadmap steht
- Object-Storage-Browser für den Bucket-Endpoint (Cross-Region-Listing, Drag-and-Drop-Upload)
- Firewall-Regel-Bulk-Editor (das meistgewünschte 2.x-Feature)
- Cost-Dashboard, das die Billing-API zieht
- Linux-Build via SwiftCrossUI — Community-Wunsch aus dem Slack
Wenn du auf Civo bist und etwas Spezielles brauchst: open an issue. Die Roadmap bewegt sich dahin wo die Community drückt.
Du willst ein vergleichbares Tool in deinem Unternehmen
Nicht jedes Team braucht eine öffentliche App, aber viele Teams brauchen ein natives internes Tool, das mit ihrem Cloud-Anbieter, ihrer Datenbank, ihrer internen API spricht — ohne die Browser-Tab-Steuer. Dasselbe Architektur-Pattern passt: dünne Swift-App, Structured Concurrency, direkter API-Zugriff, keine Dependencies. Hier starten wenn du eins für deinen Stack willst.
Im App Store ansehen — CivoCloudManager ist kostenlos im Mac App Store. Civo-Token einfügen und die Menubar wird die Cluster-Ansicht, die du dir vom Dashboard immer gewünscht hast.