Kubernetes Desktop Clients in 2026: The New Wave Beyond Lens (Tested on a Real Cluster)

For years the answer to “which Kubernetes GUI should I install?” was some member of the Lens family. Then Lens went commercial, OpenLens stalled, and FreeLens picked up the community fork. I have covered that saga in detail in FreeLens vs OpenLens vs Lens, and the web-based options in Kubernetes Dashboard Alternatives and Headlamp vs FreeLens vs Lens.

Something else has happened in the last six months, though. A new batch of desktop clients has appeared, and most of them share three traits: they are not Electron, they ship AI or MCP integration as a first-class feature, and they are built by very small teams moving very fast. Several of them reached me directly: through comments on my Medium articles, by email, or on LinkedIn.

Rather than repeat the vendors’ feature lists, I installed all of them on the same machine, pointed them at the same cluster with the same read-only credentials, and measured what they actually do and how much memory they use. This article is the result.

TL;DR

• Radar is still the most complete open-source option and now ships a desktop app and a local MCP server. It is also the heaviest of the new wave in my test.
• PodSteer is the most interesting newcomer: Apache 2.0, Go + Wails, a genuinely useful cluster assessment, and a read-only MCP server. It is three months old.
• Aptakube is the most mature and polished of the non-Electron clients, but it is proprietary and only free up to 5 nodes.
• Spinoza has the most opinionated safety features (cluster protection, drain plans) but uses the Functional Source License, which is not open source.
• KubeSpade is the only Electron app in the group. It brings an iPad client and a “bring your own AI agent” model. Closed source.
• Seabird (GTK4, GNOME) looks abandoned: no release in 14 months.
• “Not Electron” does not automatically mean “lighter”. The spread between the new clients was smaller than the marketing suggests.

How I Tested

Every client ran against the same cluster: my homelab, a three-node Talos Linux cluster running Kubernetes 1.37 with about 95 pods spread over 20 namespaces (I described the setup in moving from MicroK8s to Talos on Proxmox).

To keep things fair and safe, I created a dedicated ServiceAccount bound to the built-in view ClusterRole plus read access to nodes, CRDs and a few cluster-scoped APIs. No secrets, no exec, no port-forward, no write verbs. That restriction turned out to be a useful test in itself: you learn a lot about a client by how it behaves when it is not cluster-admin.

Each app ran in an isolated home directory on Debian 12 (x86_64), one at a time, under a virtual X display. Memory is the PSS (proportional set size) of the whole process tree, measured roughly one minute after connecting to the cluster. PSS counts shared libraries fairly, so it is a better comparison than adding up RSS across helper processes.

Two caveats before the numbers. First, this is Linux with software rendering, so absolute values will differ on macOS. Second, this is one cluster. A reader of my Radar article told me Lens was “easily pushing 2 GB” with multiple clusters open, and I believe it: memory grows with the number of clusters and the number of resources each client caches.

The Comparison at a Glance

For reference, FreeLens 1.10.3 (Electron) used ~630 MB connected to the same cluster under the same conditions.

Radar: Still the Benchmark

I wrote a full review of Radar in May and updated it with v1.16 screenshots this month, so I will focus on what changed.

Radar now ships a proper desktop app (radar-desktop) next to the kubectl radar plugin and the in-cluster Helm install. The home screen shows something none of the others had a few months ago: a local MCP server on 127.0.0.1, so a coding agent can query the cluster through Radar’s model of it instead of shelling out to kubectl.

What I liked in the restricted test: Radar told me exactly what it could not see. The timeline flagged that “some resource types are not monitored due to RBAC restrictions” and the Helm panel said “insufficient permissions” instead of claiming there were no releases. The new Upgrade impact view (removed APIs, PDBs that would block a drain, conversion webhooks without a backing Service) is also something no other client here offers.

The trade-off is weight. At ~610 MB it was the heaviest of the new clients, essentially on par with FreeLens. Radar builds a full topology and event timeline in memory, and you pay for that. Radar itself is Apache 2.0. Radar Cloud, the hosted multi-cluster version, starts at $149 per cluster per month for the Team plan.

Pick it if you want the deepest open-source client, live traffic from your mesh or eBPF tool, and the option to run it in-cluster for a whole team.

PodSteer: The Most Promising Newcomer

PodSteer is a native desktop client from Cloudresty, written in Go on top of Wails, which uses the operating system’s own webview instead of bundling Chromium. It is Apache 2.0, needs no account, and the repository is only a few months old: the first release (v0.1.0) is from 31 August 2026 and v0.6.0 came out on 3 October.

I found it through a comment its author left on my Headlamp article. That is a disclosure, not a reason to discount it, because it was the client that surprised me most.

The first screen after connecting is not a list of pods but an assessment: my cluster came back as Degraded with two warning findings, followed by a capacity panel that splits CPU and memory into requested, used, schedulable and “efficiency”. The 154% memory efficiency figure (more memory used than requested) is exactly the kind of signal that is hard to see in other GUIs.

It is also careful with data it does not have. A banner said the assessment ran “without node filesystems — those figures are missing rather than zero”. After the read-only test, that kind of honesty is the thing I value most in a cluster tool.

The Applications view groups resources by the app.kubernetes.io/instance label and shows who manages each one (Helm, an operator) and its version. It even tells you how many objects are left out because they lack the recommended labels.

The rest of the feature list is ambitious for a three-month-old project: topology with observed traffic from Istio, Linkerd, Hubble, Caretta or Beyla; Argo CD, Flux and Helm views; RBAC inspection; day-2 operations such as scale, restart, rollback and drain; and a read-only MCP server for coding agents.

Memory: ~330 MB. The topology view is the one area that needs work on a busy namespace: at the default zoom, 81 objects rendered as tiny boxes. Expect rough edges. The repository had 7 stars when I checked, so you are an early adopter.

Pick it if you want an open-source, non-Electron client that tells you what is wrong with a cluster, not just what is in it.

Aptakube: Mature, Polished, Not Open Source

Aptakube is the veteran of this group. It has been around since 2022, is written in Rust with Tauri, and its GitHub repository (875 stars) is used for releases and issues, not source code. Version 1.22.0 shipped on 27 October 2026. Rob Kooper recommended it in the comments of my Radar article, and I promised him it would be in the next comparison. Here it is.

It is the most finished client here. Opening a cluster takes you straight to a clean workload summary, and the pod list is dense in a good way: CPU and memory with usage bars against limits, restart counts, last restart time and reason, and node.

The features that set it apart are about working across many clusters at once: multi-cluster views in one window, cross-cluster resource diff, context tags with “change protection” for production, plus Argo CD, Flux, Gateway API and Karpenter views. It needs nothing installed in the cluster.

At ~300 MB it was the lightest client in my test.

The catch is the licence. Aptakube is proprietary. It is free with every feature on clusters of up to 5 nodes. Above that you get a 15-day trial, then Personal costs €7/month or €79/year and Team €5/seat/month or €59/seat/year, with SSO-based licence management on the Team plan. For a homelab or small clusters it is effectively free. For a company with real clusters it is a cheap but real line item.

Pick it if you manage many clusters, value polish over openness, and are happy to pay a small subscription.

Spinoza: Opinionated Safety, Source-Available

Spinoza, from Sophotech, contacted me on LinkedIn in August. It is a single Go binary with a React front end that runs either as a browser tab or as a desktop window. When I first looked, it was at v1.13 with one month of history. It is now at v2.2.5 (19 October 2026), so it is moving fast.

Its personality is about guard rails. The first time I connected, it offered to protect the cluster: once a cluster is protected, deleting, draining, scaling to zero or uninstalling requires typing the object’s name. Drains show the eviction plan before running. Of all the clients I tested, Spinoza thinks hardest about the destructive click.

The view I would use daily is Reserved against used: per namespace (or per workload), CPU and memory requested versus actually used, with the spare capacity highlighted. It is the fastest way I have seen to spot over-provisioned namespaces.

Spinoza is also strong on GitOps (Flux and Argo CD side by side, with a dependency graph) and reads Helm releases directly from Helm’s storage without the helm binary. In my read-only test that meant Helm showed nothing. Helm stores releases in Secrets, which my ServiceAccount could not read. Spinoza said so clearly (“Partial data: secrets could not be listed cluster-wide”), which is the right behaviour.

Memory: ~350 MB.

On licensing, be precise. Spinoza uses FSL-1.1-ALv2, the Functional Source License: you can read and use the code, but competing uses are restricted, and each version becomes Apache 2.0 two years after release. That is source-available, not open source. After the Lens licensing saga, that distinction matters.

Pick it if you want a client that actively protects production clusters from mistakes and you are comfortable with a fair-source licence.

KubeSpade: Electron, iPad, and Bring Your Own AI Agent

KubeSpade’s developer emailed me after reading my Headlamp comparison. It runs on macOS, Windows and Linux, has an iPad version (listed as “coming soon” on the App Store), stores credentials in each platform’s keychain, and can connect to EKS, GKE and AKS directly with cloud credentials, not only through a kubeconfig.

The website calls it “a fast, native Kubernetes client”. When I unpacked the Linux build, it turned out to be Electron 43 with a statically linked Go 1.25 backend that talks to the Kubernetes API. So it is the one Electron app in this new wave. The source is in private repositories: the public GitHub repo only hosts releases. It is free and needs no account. There have been 11 releases since 13 August 2026.

Connecting is straightforward: it detected my kubeconfig and let me choose which contexts to import. The overview is clean, with nodes, namespaces, Kubernetes version and warnings across the top, followed by CPU, memory and pod gauges that show usage, requests, limits and allocatable side by side.

The distinctive feature is AI. Instead of shipping its own model, KubeSpade launches the coding agent you already use, such as Claude Code, Codex, Gemini, Copilot or Cursor, in a built-in terminal. The agent gets MCP tools for the connected clusters, and write actions need your approval. The shell is deliberately started without a kubeconfig, so the agent goes through KubeSpade’s tools rather than raw kubectl. On first use it detected the two CLIs I had installed.

Here is the surprise: at ~335 MB, this Electron app used about the same memory as the Wails and Tauri clients, and roughly half of FreeLens. A thin UI with a Go backend doing the heavy lifting matters more than the shell around it.

Caveats: it is very young (about 260 downloads across all releases when I checked) and closed source, so you are trusting a small vendor with your cluster credentials. Credentials stay on the device by design, but you cannot audit that.

Pick it if you want to drive clusters from an iPad, or you like the idea of your existing AI agent working through a GUI with approval gates.

Seabird: A GNOME Client That Stalled

Seabird is a Kubernetes IDE built for the GNOME desktop with GTK4 and libadwaita, licensed under MPL-2.0 but distributed as “paid software with an unlimited free trial”. It has a healthy 1.4k stars.

Unfortunately, the last release (v0.6.0) and the last push to the repository are both from August 2025. The prebuilt Linux binary would not start on Debian 12 because it needs a newer GLib than Bookworm ships; the Flathub build is the practical way to run it. With 14 months of silence, I would not standardise a team on it today. I mention it because it still appears in many “Kubernetes GUI” lists.

Does “Not Electron” Mean Lighter?

This was the claim I most wanted to test, because it is the headline argument of almost every new client.

The picture is more nuanced than “Electron bad, native good”:

• The system-webview clients are lighter than FreeLens, but by ~2x, not by an order of magnitude.
• KubeSpade proves that Electron is not the whole story. A lean renderer with a Go backend lands in the same range as Tauri and Wails.
• What a client caches matters more than its shell. Radar is Go plus a system webview, like Spinoza, yet it uses about as much as FreeLens because it keeps a live topology and timeline of everything it watches.

On macOS, where WebKit is the system engine, the webview clients usually look even better. The bigger benefit of Wails and Tauri is often download size (PodSteer’s AppImage is 15 MB, against 141 MB for KubeSpade and 199 MB for FreeLens) and fewer Chromium security updates to chase.

Which One Should You Choose?

• You want open source, full stop: Radar or PodSteer. Radar for depth and maturity, PodSteer if you value the assessment-first approach and a lighter footprint.
• You run many clusters and want polish: Aptakube, and budget a few euros a month per seat if your clusters have more than 5 nodes.
• You worry about someone draining production by mistake: Spinoza’s cluster protection is the best guard rail here.
• You want AI to operate the cluster through a GUI, with approval: KubeSpade’s bring-your-own-agent model, or the MCP servers in Radar and PodSteer if you prefer to keep the agent in your own terminal.
• You manage clusters from an iPad: KubeSpade is the only option in this list.
• You need extensions and a large community today: stay on FreeLens with its extensions, or move to Headlamp, which has the backing of Kubernetes SIG UI (comparison here).

My own setup after this test: Radar stays as my main client, and PodSteer goes on the watch list. If it keeps this pace for another six months, it will be a serious contender.

Disclosure

KubeSpade’s developer contacted me by email and Spinoza’s team on LinkedIn. PodSteer’s maker recommended it in a comment on one of my articles. Nobody paid for coverage or saw this article before publication. All tests used the public builds available on 28 October 2026.

Frequently Asked Questions