Skip to content
TAA

Case Study

CivoCloudManager — building a native Civo client in public

A free, native macOS app for Civo Cloud. Built in public for the Civo community. Swift 6, SwiftUI, zero dependencies, open roadmap.

May 5, 2026 · Marcel R. G. Berger · 5 min

  • case-study
  • build-in-public
  • civo
  • kubernetes
  • macos
  • swift
Share

Civo is the cloud provider I trust with my own production workloads. When I needed a faster way to manage clusters, S3 buckets and firewalls without living inside a browser dashboard, I built CivoCloudManager — a native macOS app that talks directly to the Civo API. Then I shipped it for free to the App Store and decided to build the rest of it in public, for the Civo community.

This post is the architecture write-up and the roadmap. Two months in, it’s running on real desks.

Why build it, why give it away

Civo’s web dashboard is good. But “good web dashboard” is still a browser tab in a sea of tabs, with a refresh button and no menubar status, and you cannot keep ten cluster contexts in front of you without losing your mind. A native app fixes that — and the Civo community has been asking for one in the Slack channels for years.

I had two choices: wait for someone to build it, or build it myself and not charge for it. Giving it away makes it part of how I’d want the Civo ecosystem to feel. It also turns out to be the most honest portfolio piece I can put in front of cloud-platform-savvy clients.

The App Store distribution is free; the source is on GitHub under a license that says: use it, fork it, learn from it.

The architecture — zero dependencies, pure SwiftUI

The whole app is one Swift Package, no third-party libraries. That sounds like a vanity flex; it isn’t. It means the binary is small, the security surface is tiny, and there’s no transitive-dependency drift to manage. For an app whose entire job is “talk to two APIs”, you do not need a framework.

One layer that talks to Civo

A single CivoClient actor wraps the Civo HTTP API. Token comes from the macOS Keychain — never from disk, never logged. Every request is structured concurrency: async let for the parallel calls (instances + clusters + buckets fan out from a single screen load), no callbacks, no Combine chain to debug.

One layer that talks to Kubernetes

The Kubernetes integration goes directly against the K8s API — no kubectl shell-out, no helper binary. CivoCloudManager downloads the kubeconfig from Civo, parses it, and from there speaks the Kubernetes API just like any other client would. Pod logs stream over a websocket; metrics come from the metrics-server when present, gracefully empty when not. Eight languages, all SwiftUI strings, all bundled.

Tap the menubar icon and you see a 480px window with the cluster you used last, live pod metrics scrolling, an inline log tail you can pin. No tab. No refresh. That is the entire reason the app exists.

Build-in-public principles

Three commitments I’m holding myself to:

Public roadmap. The next features are on GitHub Issues with rough dates. When something slips, the issue gets updated, not silently moved. When something ships earlier than planned, the commit links the issue.

Visible decisions. Architecture changes — adding observability, choosing how to store credentials, deciding what to skip — get a short note in the repo’s decisions/ folder. The point isn’t process theatre; it’s that someone forking this in a year will see why the code is shaped the way it is.

Community-driven prioritisation. A real ask in the Civo community Slack outranks anything on my speculative roadmap. The 2.0 release reordered everything because three different users reported the same DNS pain point in the same week.

What I learned shipping it

Native macOS is back. People want this. The “everything is Electron now” era is ending, and a 12 MB Swift app that boots in 80 ms in a sea of 400 MB Electron tools genuinely surprises people in the best way.

Civo’s API rewards a thin client. No middleware needed. Rate limits are generous, response shapes are clean, the Bearer-token model is straightforward. If you want to build something on top of Civo, you can — and the API does not get in your way.

Free + good is a marketing strategy. I have not run a single ad. The app has organic reviews because Civo users tell other Civo users about it. That is the only kind of marketing that scales for a tool like this.

What’s next on the public roadmap

  • Object-storage browser for the bucket endpoint (cross-region listing, drag-and-drop upload)
  • Firewall-rule bulk editor (the most-requested 2.x feature)
  • Cost dashboard pulling from the billing API
  • Linux build via SwiftCrossUI — community ask from the Slack

If you’re on Civo and you want something specific: open an issue. The roadmap moves toward where the community pushes.

Want a similar tool inside your company

Not every team needs a public app, but plenty of teams need a native internal tool that talks to their cloud provider, their database, their internal API — without the browser-tab tax. Same architecture pattern applies: thin Swift app, structured concurrency, direct API access, no dependencies. Start a project brief if you want one for your stack.


See it on the App StoreCivoCloudManager is free on the Mac App Store. Drop in your Civo token and the menubar becomes the cluster view you wished the dashboard had.

Share