JET Pilot: a Kubernetes desktop IDE with a mouse and a keyboard

Built because the good-looking cluster tools went commercial

JET Pilot describes itself as an open-source Kubernetes IDE, and the origin story in the documentation is unusually blunt about why it exists. It was created out of frustration, as all the good-looking Kubernetes IDEs went commercial. The comparison the project draws is with k9s, which it says works great but heavily relies on keyboard input, and JET Pilot aims to combine a keyboard-first workflow with a polished, mouse-friendly desktop interface. That framing tells you the audience: cluster operators and developers who want the speed of a terminal tool but do not want to memorise key bindings for every action. The stack follows from the goal, with Rust and Tauri so the app stays small and fast, and Vue 3 for the interface. The homepage is jet-pilot.app, the licence is MIT, and the project makes two promises that matter for a tool that touches production infrastructure: no account and no telemetry. It uses the kubeconfig files and kubectl that are already on the machine, and connects cloud accounts only when asked.

A Vue interface over a Rust core, with a bundle budget

The tree shows a Tauri application with a separated front end, a src-tauri/ directory for the Rust side and a src/ directory for the Vue code, plus dev/ for a harness, tests/, scripts/ and docs/. The package.json is where the engineering discipline shows. The dev script builds a Rust binary named jetpilot-auth through cargo before starting tauri dev, with RUST_BACKTRACE enabled. There is a build script for tauri build, separate vite:dev and vite:build scripts, and a check script that runs cargo check inside src-tauri. Two entries stand out for anyone who cares about a desktop app's footprint: a size:check script that runs a node script named check-bundle-size.mjs, and an analyze script that builds with a separate vite.analyze.config.mts and then runs that same script with an --explain flag. There is a bundle-budget.json in the root, so the front-end size is a checked quantity rather than a matter of opinion. Tests run under vitest, type checking is vue-tsc with no emit, and husky is wired in through a prepare script, with .commitlintrc.yml and .husky/ in the tree for commit conventions.

Every cluster in one list, credentials in the system keychain

The clusters hub is the centre of the application. Every cluster from every kubeconfig and cloud account appears in one list, with live status, names, colours, folders and tags. The cloud providers it connects are listed explicitly: AWS, Google Cloud, Azure, DigitalOcean, Akamai and Linode, Civo, Scaleway, Vultr and Exoscale, and a cluster can also be pasted, imported or entered by hand. The credential handling is the part to note, and it is handled by not inventing a new store. The documentation says credentials live in the system keychain of the machine running the app, so the app reads the credentials the operating system already holds rather than storing secrets of its own, which is consistent with the no-account, no-telemetry promise. Because the app works from kubeconfig files, it inherits whatever contexts those files contain, including the ones a user already uses with kubectl, so there is no separate login step to explain to someone on the team.

Guardrails sit in front of destructive actions

Two safety features address the obvious risk of a mouse-driven interface on production clusters. Protected clusters ask you to type the name before destructive actions, which is a confirmation that costs a few seconds and removes the possibility of a mis-click on a workload in production. Read-only clusters cannot be changed from JET Pilot at all, which is a stronger guarantee than a warning, and it is the setting a platform team would want for accounts that some engineers may inspect but not modify. The demo in the documentation shows exactly that moment, a protected production cluster asking for the name before a delete. The rest of the object model follows the same pattern of small, specific affordances rather than a general permission system, since access review is handled by a separate view that answers what a user, group or service account may do and shows the binding behind each answer.

GitOps, Helm, metrics and operators share one window

The feature list is where JET Pilot positions itself against the built-in dashboards. GitOps support puts every Flux Kustomization, Flux HelmRelease and Argo CD Application in one place, problems first, with reconcile, suspend, sync and refresh actions. Helm support shows releases and their history straight from the cluster, searches charts across the configured repositories and Artifact Hub, and performs installs and upgrades with a diff. Usage history draws CPU, memory and network charts from the cluster's Prometheus, which the app finds by itself and queries through the API server, or from metrics-server. For custom resources there are printer columns and specific views for cert-manager, Gateway API, Karpenter, KEDA, External Secrets and Prometheus Operator. Around that sit the daily drivers: a resource graph relating Services, Deployments, ReplicaSets, Pods, ConfigMaps and Secrets with live health indicators, a structured log viewer that follows logs across every pod of a workload and parses JSON log lines into fields, a full YAML editor for creating and editing any object, port forwards that follow their pod through rollouts, custom actions from small YAML files, and events, scaling, rollouts, cordon and drain.

Installing on macOS, Linux and Windows

The application is downloaded from the releases page or from jet-pilot.app, and it updates itself. On macOS the Homebrew route is a tap:

brew install --cask unxsist/tap/jet-pilot

The tap's cask clears the macOS quarantine flag, so the app opens immediately and keeps itself updated. A note in the documentation explains a change that will trip up anyone who installed the app earlier: since October 2026 Homebrew only accepts apps notarized by Apple in its main cask repository, so JET Pilot left it, and the switch is a single command, `brew uninstall --cask jet-pilot && brew install --cask unxsist/tap/jet-pilot`, which keeps the settings. If you install the .dmg yourself, for Apple Silicon or Intel, macOS will report the app as damaged or unverifiable, and the fix is a single xattr command that clears the quarantine attribute on the application bundle, run once after the copy into Applications.

On Linux there are packages for x64 and ARM64, a .deb for Debian and Ubuntu, an .rpm for Fedora, RHEL and openSUSE, and an AppImage for any distribution. On Windows the .exe or .msi installer is unsigned, so SmartScreen may warn and the fix is to choose More info and Run anyway. The app also uses kubectl for some tasks and helm to install, upgrade and roll back charts, though browsing releases does not need it, and it can download both for you, verified against their official checksums, from Settings and Advanced.

Signing, telemetry and the release cadence

Three facts bound what this project can promise. The first is that the application is not notarized by Apple, and the documentation explains the reason plainly: it is free and open source and the maintainers would rather not pay Apple's yearly developer fee. That is a defensible choice for a volunteer project, and the cost is a manual quarantine removal on every fresh macOS install, which is a small but recurring tax for anyone rolling the app out to a team. The second is that the Windows installer is not code-signed, so every new machine sees a SmartScreen warning. The third is the dependency on the Kubernetes command line tools, which the app can download and verify for you but which are still part of the operating model, and the built-in terminal deliberately opens with kubectl preconfigured for the current context while never modifying the kubeconfig on the machine. On cadence, the release list shows v2.2.3 on 2026-10-18, v2.2.2 and v2.2.1 both on 2026-10-15, and the last push to the repository was on 2026-10-18, so the project is shipping frequently. The per-release detail lives in CHANGELOG.md and on the changelog page of the site.

Editorial conclusion

JET Pilot suits platform engineers who want a graphical Kubernetes client that still behaves like a keyboard-first tool, since the command palette, the local terminal and the YAML editor all sit next to the mouse-driven tables. It is the wrong choice for a team that requires signed and notarised desktop binaries, because the documentation is explicit that neither is provided. Before adopting it, confirm that the clusters are reachable through the kubeconfig files the app reads, and check the guardrail behaviour, since protected clusters ask you to type the name before a destructive action and read-only clusters cannot be changed from the app at all.

Frequently asked questions

Official sources

1. License: MIT
2. Project website
3. README
4. Releases
5. unxsist/jet-pilot on GitHub