My Phone Was Better at Kubernetes Than My Laptop. So I Fixed the Laptop.

Roam is now on macOS, Windows and Linux. And S3Deck, the storage client I built because I couldn't stop.

The screen I wanted at 10AM on a Tuesday. Same idea as the 2AM one, just more pixels.

A few months ago I wrote about driving home from a coffee shop to run one kubectl command, and building a phone app so I'd never have to do that again. (Part 1)

This is the sequel, and it starts with an embarrassing admission.

After shipping Roam for mobile, I'd sit down at my desk, open the desktop Kubernetes client I'd used for years, and catch myself reaching for my phone instead.

Not because a phone is a better place to run a cluster. It obviously isn't. It was because the phone app opened faster and read faster, and it didn't ask me to sign in, upgrade or dismiss anything before showing me a pod.

That's backwards. A 6-inch screen shouldn't beat a 27-inch one.

The desktop tool had been drifting for a while. Each release got a little heavier. A few more of the features I used every day quietly moved into a paid tier. A few more bugs became things I'd learned to click around. None of it was dramatic on its own. All of it together was a tax, and I'd already decided once that I'm done paying taxes I can fix myself.

So I built Roam for desktop.

The thesis changes when the screen gets bigger

On the phone, the design thesis was simple: 95% of on-call is reading. Make reading effortless, and make the small set of writes safe.

That's still true at a desk. But the desk changes what you're reading.

On the phone, you're answering "is anything on fire, and can I put it out from here?" At the desk you have time and room, and the question is almost always the next one:

What changed?

Every incident I've worked on has a moment where someone asks it. The answer is usually scattered across a kubectl history in someone's terminal, a Helm release, an Argo CD sync, and a Slack message that says "small fix, shouldn't affect anything."

So the desktop version is built around two ideas:

1. Start from what needs you. Same as the phone.
2. Make "what changed?" a screen, not an investigation.

What it actually does

A to-do list, not a resource tree.

The home screen is a list of problems. Crash loops, unschedulable pods, nodes under pressure, failing jobs, certificates close to expiry, each with a suggested next step. If the list is empty, you can go back to your coffee.

Caption: Who changed it, what changed, and a button to put it back.

Change history. Roam records changes made through kubectl, Helm and Argo CD, with the author and the diff, and lets you revert one in a click. If I lost every other feature, this is the one I'd rebuild first.

Apps, not just objects. Roam groups Deployments, StatefulSets, Services and Ingresses into the apps they actually make up, with a map of traffic flow and dependencies. Kubernetes thinks in objects. Humans debugging under pressure think in apps.

Helm, metrics and certificates. You get release history and values diffs between revisions. Metrics have rollout markers drawn on them, so "did the deploy cause the spike?" takes a glance instead of a timestamp comparison. There are also TLS expiry checks, cert-manager support, and any CRD your cluster has.

Everything from the phone, plus a keyboard. Live logs with severity colours, search and the previous container's run. Shells into containers and nodes, with command suggestions. Scale, restart, edit YAML. Sign in to EKS, GKE or AKS with your cloud account, or import any kubeconfig or token.

It runs on macOS 13+ (Apple Silicon and Intel), Windows 10 and 11 (x64 and ARM64), and Linux.

Still no backend. Obviously.

The no-backend argument from part one matters even more on desktop, because the desktop is where the admin kubeconfigs live.

There is no Roam server and no account. The app talks directly to your API server, and your credentials are encrypted on your machine. There's nothing to sign up for, nothing on my side to breach, and nothing that phones home with your cluster data.

A desktop app that holds production credentials also has to be honest about how it gets onto your machine:

• The macOS build is signed and notarized by Apple.
• Every release on GitHub lists SHA256 checksums.
• The Windows installer is not code-signed yet, so SmartScreen will give you a suspicious look. The Microsoft Store build doesn't have that problem.

I'd rather tell you that here than have you find out from a warning dialog.

The technical part

In part one I said the four-language call path (React Native → TypeScript → Kotlin/Swift → Go + client-go) made the build pipeline my least favourite part of the project, and that it was still worth it because I got kubectl's auth behaviour for free.

On desktop, that decision paid me back.

The AI part, now with your model

On the phone, the model runs on-device through llama.cpp. On desktop you have more RAM and more choice, so you pick: your own provider, or Ollama running locally if you'd rather nothing leave your machine. Roam is still never in the middle.

The desktop version explains, in plain language, why a workload is failing.

The biggest lesson from the phone carried over too: small models don't need better prompts, they need a smaller job. Someone running an 8B model in Ollama on a laptop is exactly who that lesson was for.

And then I built a second app

Here's something I've noticed about myself: once you remove one daily annoyance, the next one gets very loud.

Mine was object storage. Production assets in AWS S3. Media in Cloudflare R2, because egress fees. MinIO for local development. That's three consoles with three sets of quirks, and every time I needed to move data between them, there was an aws s3 sync or rclone command I had to look up again.

So I built S3Deck: one desktop app for AWS S3 and every S3-compatible storage, including Cloudflare R2, MinIO, Backblaze B2, Wasabi, DigitalOcean Spaces, Ceph, or any endpoint that speaks S3.

Local on the left, bucket on the right. Drag, then walk away.

It's a real file manager for buckets:

• Two panes. Local on one side and a bucket on the other, or bucket to bucket.
• Transfers that keep going. Parallel multipart uploads, auto-resume after a dropped connection, a bandwidth cap, and checksum verification when the last part lands.
• Two-way folder sync that asks you file by file when both sides changed, instead of guessing.
• Cross-provider migration. Move a whole bucket from S3 to R2, or from MinIO to B2, as a job you can pause, continue or cancel.
• Bucket settings, visually. Policy JSON with validation and a plain-English explanation of what it allows, a CORS rule builder, lifecycle, versioning and ACLs.
• Presigned links, version history with one-click restore, CloudFront invalidation, and parsed access logs.

It follows the same rules as Roam, because I no longer know how to build software any other way. There's no account, no telemetry and no relay. Access keys go into Keychain, Credential Manager or Secret Service, never a plain config file.

It also has a read-only mode. Mark a production connection read-only and S3Deck blocks every delete and overwrite on it. It's Rule 2 from the AI section, applied to a whole connection: a single misclick should never be able to empty a bucket.

What building for desktop taught me

"Cross-platform" means three operating systems, each with opinions. macOS wants notarization. Windows wants a code-signing certificate before SmartScreen stops warning people. Linux wants the right WebKitGTK version, which is never the one on the distro you tested.

App store submission, again. Last time I said app store submission is a distributed system with bad error messages. I've now done the Mac App Store and the Microsoft Store as well, and I stand by every word.

Would I do it again

Same answer, same reason. I was still the user.

The difference is that this time I was the user at 10AM on a Tuesday, mildly irritated instead of furious at 2AM. That turns out to be just as useful for product research, and much better for my blood pressure.

Roam is free on every platform:

• Desktop (macOS, Windows, Linux): https://kuberoam.dev
• App Store: https://apps.apple.com/app/id6794656342
• Google Play: https://play.google.com/store/apps/details?id=dev.roam
• Issues and feature requests: https://github.com/kuberoam/kuberoam

S3Deck is free on macOS, Windows and Linux, with mobile in progress: https://s3deck.com

If you run a cluster or juggle buckets across providers, I'd genuinely love for you to try them and tell me where they fall short. I've still mostly been testing against my own clusters, my own buckets and my own habits, and I'm sure there are workflows I've never considered because they aren't mine.

Bug reports are still a compliment. Feature requests are still a bigger one.

And if you've ever picked up your phone because the Kubernetes client on your laptop was too slow, this one's for you.