DEV Community: UDAWPK

0.25.3: the manifest linter is on by default now (and the telemetry prompt we promised is live)

UDAWPK — Wed, 14 Oct 2026 08:56:30 +0000

Every ROZOOM release before 0.25.3 shipped the manifest linter off. You could turn it on per cluster, but nothing was checked unless you went looking for the toggle — which meant most people never saw it, and the first sign of a bad manifest was still kubectl apply failing, or worse, succeeding with the wrong value.

What changed

The linter is on by default for every cluster you connect, starting the moment you connect it. No setup, no toggle to find first.

What it actually checks, straight from the linter code:

Valid YAML syntax (multi-document aware)
Duplicate keys within the same scope
Bad indentation — tabs are rejected outright, odd (non-2-space) indentation gets flagged
Schema validation against the real Kubernetes API via kubeconform — wrong field names, wrong types, missing required fields

None of that logic is new. What's new is that it runs without you asking.

You can still turn it off, same as before — per cluster from the cluster card, or everywhere from a sidebar toggle. The cluster card now also tells you how to turn the linter back on if it's off, so the setting doesn't disappear once you've touched it.

The telemetry prompt we said was coming

Back in September we wrote about shipping a consent flow before turning on any collection. 0.25.3 is the release where that prompt actually goes live.

It shows up once, after your first scan finishes — not during onboarding, not before you've done anything. The ask: anonymous usage counts for three core actions, an anonymous install hash, no personal data, no session recording. Click "No thanks" and it's off permanently, no re-asking. Close the toast without choosing and it comes back after your next first scan. Running with Do Not Track on, or without a telemetry key configured at all, skips the prompt entirely — there's nothing to consent to.

Where this sits free vs. paid

Both of these — the linter and the telemetry controls — ship in the same free, Apache 2.0 build as everything else. There's no paid tier that unlocks local features. The only line we draw is hosted functionality that needs our own server; anything that runs on your machine stays free.

Full release notes, checksums and signatures: app-v0.25.3 on GitHub

ROZOOM is Apache 2.0: github.com/ceh13-community/rozoom

https://rozoom.app

Why our Kubernetes UI installer used to be 500 MB (and isn't anymore)

UDAWPK — Thu, 01 Oct 2026 19:42:20 +0000

Every ROZOOM release used to ship one installer per platform, and it bundled the full CLI toolset whether you used it or not — kubectl, helm, plus about 20 more tools like velero, trivy, doctl, stern, kustomize. On Linux that meant a build pushing half a gig for a tool most people run against a cluster they already manage day to day.

0.25.0 splits that into two builds.

Slim vs full-offline

Slim still bundles kubectl and helm right inside the binary, as sidecar tools — no system install, no PATH dependency. What it drops is the extended CLI set: velero, trivy, doctl, stern, kustomize and about 16 more. Those features aren't broken in slim, they're just hidden in the UI. It's the default download.

Full-offline ships everything: the full CLI set and all assets, for machines with no internet access at all — air-gapped clusters, restricted networks. Across platforms it runs 199-486 MB.

Platform	Slim
Windows (.exe)	31.6 MB
Windows (.msi)	46 MB
macOS (.dmg, Apple Silicon)	42.3 MB
Linux (.deb/.rpm)	47.1 MB
Linux (.AppImage)	115.4 MB

If you already installed ROZOOM before 0.25.0, you're on full-offline. Slim installs from 0.25.0 on update themselves automatically going forward; anything on 0.23.1 or older gets the full-offline build until you switch by hand.

How that compares

We checked what a comparable open-source desktop Kubernetes UI ships. Headlamp's Linux .deb (v0.45.0) is 124 MB. ROZOOM's slim .deb/.rpm is 47.1 MB — same package format, about 2.6x smaller.

The Linux .AppImage build doesn't get the same win: 115.4 MB, barely under Headlamp's 124 MB. We're still checking with engineering why AppImage doesn't shrink the way the other slim builds do — if you're on Linux and size matters, .deb/.rpm is the smaller path right now, not AppImage.

That gap between 47 MB and 486 MB on the full-offline end is the same admission either way: we shipped that size by default for months before splitting the build. The split exists because bundling everything by default was the wrong tradeoff for the common case.

Full release notes

app-v0.25.0 on GitHub — platform-by-platform artifact table, checksums, signatures.

ROZOOM is Apache 2.0: github.com/ceh13-community/rozoom.

https://rozoom.app

What it takes to trust an open-source app that updates itself

UDAWPK — Fri, 18 Sep 2026 11:59:27 +0000

An auto-updater is a strange thing to ship in open source. You're asking someone who chose your project specifically because they could read the code to now trust a binary that lands on their machine without them clicking anything.

ROZOOM's 0.23.0 release ships the first version of that channel: a background check, a silent download, and one entry in the notification bell - no toast, no modal stealing focus - "Rozoom 0.23.1 is ready / Restart to finish updating," with a single action, "Restart now." Nothing else changes until you click it.

Here's what that channel actually is, and what happened before we trusted it enough to ship it.

What actually updates itself

The updater works on AppImage (Linux), Windows, and macOS (Apple Silicon) builds. Deb and rpm packages don't auto-update - that's not a footnote, it's the whole story if you're on one of those: you keep updating by hand, the way you already do.

If you're on 0.22.6, this update won't find you automatically. 0.22.6 doesn't have an updater in it at all - there was nothing there to check with. Install 0.23.0 by hand, once. From there, supported platforms take over.

The part that isn't in the release notes

Every update ROZOOM downloads gets checked against a signing key before it's allowed to install. Get that key wrong once and you've built a supply chain for anyone who compromises it.

Ours almost was. The key pair got sent through a messenger app before it ever shipped - a private key and its password, together, outside the places we'd normally trust either. No release had used it yet, so we didn't debate it: we rotated the pair and treated the old one as burned. The cost of doing that before publishing is one line in a config file. After publishing, it's every installed copy losing its update channel for good.

The second thing was less dramatic and more revealing. Turning on this feature meant making the AppImage build a hard requirement instead of a "best effort" step - and the moment we did, it stopped passing. It turned out our AppImage build had been silently failing behind a continue-on-error flag since 0.22.3. Every Linux release for months had shipped without one, and CI stayed green the whole time.

Fixing it for real took three passes, each one a public PR:

the build was resolving system libraries from vendored dependency folders instead of the host, and fell over (#160)
that fix exposed a second one: a GTK plugin inheriting the same lookup path and grabbing an incompatible zlib (#161)
only after both landed did a full run go green on Linux, Windows, and macOS together (#159)

What we watched happen

0.23.1 existed for exactly one reason: prove the update path works outside CI, on a real machine, not just that the artifacts exist. We installed 0.23.0 fresh, let the updater find 0.23.1 on its own, and let it run start to finish - background check, silent download, one entry in the bell.

Clicked "Restart now," confirmed the one prompt it puts up - any open exec sessions close - and the app came back. Sidebar showed 0.23.1, notification gone, binary hash matching the published release asset.

Open source

ROZOOM is Apache 2.0: github.com/ceh13-community/rozoom.

https://rozoom.app

We built a Kubernetes UI that scores your cluster, not just shows it

UDAWPK — Tue, 25 Aug 2026 08:06:03 +0000

Every Kubernetes UI we tried does the same thing: it shows you what's running. Pods, namespaces, nodes, workloads. kubectl does this in text. Lens and Headlamp do it in a GUI. k9s does it in a terminal. All of them answer "what's there."

None of them answer "what's actually wrong, and what should I fix first."

That's the gap we built ROZOOM to close.

The problem: state isn't the same as health

You can stare at a dashboard full of green pods and still be one misconfigured resource limit away from an incident. Visibility tools show you the cluster. They don't tell you which of the 40 things you're looking at actually matters right now.

We kept ending up back in kubectl, cross-referencing symptoms manually, because nothing we used would just tell us: here's what's broken, here's what's risky, here's what to fix first.

What we built

ROZOOM is a desktop app (Tauri + SvelteKit, macOS/Linux/Windows) that connects to a cluster and runs two scores against it:

• Runtime Health Score: what's failing right now across control plane, nodes, workloads, observability, and platform hygiene.
• Config Reliability & Security Score: configuration risks that are likely to cause an incident before they do.

Issues are ranked by impact, with remediation guidance attached. You're not scrolling through every resource looking for the one that matters. It's surfaced.

How it connects

30-second version: download the installer, launch, click "Connect a cluster."

• Local cluster (minikube, kind, k3d, Docker Desktop), auto-detected, one-click read-only scan, connect.
• Remote cluster: paste the API server URL and a service-account token. No OIDC setup required for this path.
• Existing kubeconfig also works, including OIDC, cloud import, exec plugins, and Vault.

There's no agent, no operator, no DaemonSet. Nothing gets installed on the cluster. ROZOOM talks to the API server directly from your machine, the same way kubectl does. Disconnect, and nothing is left behind.

Where this sits next to what you already use

• vs Lens: both are desktop apps, so that's not the difference. The difference: no sign-in, no cloud account, Apache 2.0 license, and scoring instead of just a tree view.
• vs k9s: k9s is faster if you already live in a terminal. ROZOOM is for the moment you need to hand a cluster to someone who doesn't, and still get a ranked answer instead of a wall of resources.
• vs Headlamp: closest in spirit (open source, GUI). The scoring and ranked remediation is the part we haven't seen elsewhere.

Open source

ROZOOM is Apache 2.0: github.com/ceh13-community/rozoom | https://rozoom.app. If you're building health signals or config risk checks for Kubernetes, that's exactly the kind of contribution we want.