Why Sextant

A longer story of Sextant: why it exists, what it does, how it is built and where it falls short. A Russian version is on Habr.

Why another Kubernetes client

Sextant is a desktop Kubernetes client in Rust and Tauri 2: what you did in Lens, without an account, a server or telemetry, plus a built-in MCP server for AI agents. It is open source (MIT or Apache-2.0) and runs on Linux, macOS and Windows.

I'm Yuriy, CTO at REES46, with 25 years in IT. Kubernetes is daily work for me: high-load systems at 120 thousand requests a second and several clusters at once. For years Lens was open on my screen from morning to night, and three things wore me down.

The first was commercialisation. In 2022 Lens 6 introduced Lens ID and subscriptions; the free Personal tier is for individuals and small companies only. In December of the same year OpenLens 6.3 lost its logs and terminal, which stayed only in the commercial product. Lens 2026.10 added Flux, Argo CD and cost monitoring, but EKS/GKE/AKS clusters and extensions are marked PREMIUM.

The second was stability, and this is personal experience. Leave Lens overnight with a couple of terminals and open logs, and by morning the machine is likely to be crawling. Port-forwards hang, and you notice only when the service stops answering. The Lens tracker has similar reports (#7227, #6265, #6248). Part of it is the price of Electron: a whole Chromium ships with every app.

The third was AI agents. I wanted Claude Code to look at a cluster without getting my admin kubeconfig in its sandbox: with per-cluster rules, approval of every change and a log.

What it does

• Every resource in live tables, CRDs included, with a YAML editor that knows the cluster's own schema, scale, restart, cordon, drain, rollout history and rollback, custom columns, a command palette (Ctrl+K).
• Logs, shells, port-forwards: logs of a whole Deployment in one stream, shells in containers, debug containers, a shell on a node, file copy, port-forwards that reopen the stream on every connection and switch to another ready pod.
• Problems and notifications from one rule set; a change timeline (what changed, when, by whom); "why didn't it scale"; "why does this Service get no traffic"; best-practice checks; a cleanup of unused objects that never offers what Helm, Flux or Argo CD manage.
• GitOps: Flux and Argo CD with sync, suspend/resume and diff, through the Kubernetes API only; Argo Rollouts with the same patches as the kubectl plugin.
• Understanding the cluster: right-sizing from Prometheus history, cert-manager and TLS expiry, RBAC who-can-do-what, network policy connectivity and coverage, Istio and Linkerd, a live traffic graph, costs from OpenCost, a resource map with "what a delete would break".
• Safer changes: a server-side dry run and a diff before applying YAML or upgrading Helm, on by default for clusters with prod in the name.
• Image files straight from the registry: no exec, no pull, no local docker.
• Extensions in sandboxed iframes with an SDK, and the interface in 14 languages.

Why Rust and Tauri 2

Everything that touches the cluster lives in Rust; React only draws. Data, secrets and permission checks never depend on what happens in the web part. Tauri 2 uses the system WebView instead of a bundled Chromium, and kube-rs is a mature Kubernetes client.

The project has three layers. sextant-core is a library on kube-rs: kubeconfig, discovery, watch, actions, logs, exec, port-forward, metrics, Helm. It does not depend on Tauri, and CI checks that. The Tauri layer holds commands, app state, the PTY and the MCP server; every subscription and session is registered in one AppState, so closing a cluster or the window closes everything that was open. React and TypeScript draw the interface; types across the boundary are generated from Rust, and CI fails if they drift.

A few decisions keep it fast on big clusters: streams reach the window through Tauri channels rather than events (WebKit kept the memory of evaluated event scripts); lists arrive in pages of 500 and a table holds up to 20,000 objects; label search goes to the API server; changes are never retried automatically; Secret values are stripped in the core.

An MCP server you can let into production

The agent gets not a kubeconfig but 35 Sextant tools, and every call goes through the cluster's rules, an approval in the window and the log.

• Closed by default. Access to every cluster is Off until you choose Read-only, Read + write, Full or Custom rules (namespaces x kinds x actions). An unknown field in the rules reads as Off.
• Checked right before the action, with fresh settings. A tool touching several objects checks them all before sending anything. A cluster-scoped kind is always treated as namespace-less, so "team-a x all kinds x Delete" cannot delete a Node.
• Approval in the window: agent, cluster, action, target. No answer in 120 seconds means no; no window means no. "Allow" ignores the keyboard for the first second.
• Secret values are a separate permission that no preset grants. Dry runs never tell an agent whether a value would differ.
• Network and token: the server listens on 127.0.0.1 only; requests with an Origin, a foreign Host, a wrong Bearer or a body over 4 MB are refused before the MCP layer. The token is a 0600 file that never reaches logs.
• Not for agents: node shells, exec into node-shell pods, port-forwards to hostNetwork pods, bulk cleanup, kubeconfig edits.

Read-only diagnostic tools give the agent the same answers the window computes: problems, "why no traffic", connectivity, permissions, recent changes, autoscaling. Each answer is built only from what the agent may read and filtered again in Rust.

All of the code was written by a model

Not one line of Sextant was typed by hand: Claude Code generated the Rust and TypeScript, tests included. The work is split:

• The human writes requirements, accepts architecture decisions, reviews and decides what ships.
• The model writes code and tests, keeps the documentation, runs the checks and fixes what breaks.
• The project memory is written so that the model reads it too: an agents file and 110 ADRs with the reasons for decisions. A new session starts from that history, not from zero.

Every change goes through Rust and TypeScript tests (1449 and 3282 today), a check of the types across the boundary, integration tests and e2e on a kind cluster, and CI on Linux, macOS and Windows. Bugs happen and are caught the same way. The first commit was on 11 October 2026; 0.21 shipped on 21 October.

Modern models can carry a large project across several languages when they get clear requirements, written-down decisions and strict checks. Without a person who understands the domain and answers for decisions, there would be no such result.

Numbers

Sextant 0.11.1 against Freelens 1.10.3 (an open fork of Lens on the same Electron) and Lens 2026.10 on the free Personal licence. One machine (Linux, 16 cores, 27 GB), one kind cluster, a separate profile per app, a 1280x800 window, no swap; all three show the pods of all namespaces.

Measure	Sextant 0.11.1	Freelens 1.10.3	Lens 2026.10
Start to window, s	0.6-0.7	3.4-4.7	2.4
Memory, 44 pods, MB	326	649	862
Memory, 544 pods and 150 CRDs, MB	376	672	877

Memory is the PSS sum over all the app's processes: the Rust core and WebKit processes for Sextant, the Electron processes for the others.

Where we lose. On 500 extra pods Sextant grows more: +50 MB against +23 for Freelens and +15 for Lens. Watched objects are still kept as JSON trees in the core, about four times the JSON itself; an external pull request with a compact representation is under review. Installers are not code-signed yet, so macOS and Windows warn on the first run. macOS and Windows are tested in CI but not on real machines, and EKS/GKE/AKS discovery was tested with fake CLIs, not real accounts.

Try it

brew install --cask friendsofkubernetes/sextant/sextant      # macOS
scoop bucket add sextant https://github.com/FriendsOfKubernetes/sextant-scoop
scoop install sextant/sextant                                # Windows

Or take .deb, .rpm or .AppImage (x86_64 and arm64), .dmg or .msi from the latest release. Sextant finds your kubeconfig by itself. Documentation is in the wiki, questions in Discussions, bugs in issues. Sextant is free and will stay free: no paid tiers, no accounts, no "pro" features.