KDash: a Rust terminal dashboard for Kubernetes, and what it will not do

The gap KDash fills between kubectl and a browser dashboard

kubectl answers one question at a time. You type a command, read the output, type another. When you are chasing a pod that keeps restarting, that loop gets long: list pods, describe one, get logs, check the deployment, repeat. KDash is a terminal user interface that keeps those views on screen and lets you move between them with single keystrokes. The README describes it as "a simple terminal dashboard for Kubernetes built with Rust", and the repository's topics list it as a TUI for k8s monitoring.

The audience is narrow on purpose. This is for engineers who already have a kubeconfig and a working kubectl, who spend their day in a shell, and who want to watch cluster state without alt-tabbing into a browser. It is not a platform for handing to a support team that does not know what a namespace is. Everything happens inside the terminal, driven by the keyboard.

How the KDash TUI talks to your cluster

KDash is a client-side binary. There is no server component, no CRD, and nothing to install inside the cluster. The Cargo manifest lists the kube crate with the client, rustls-tls, oidc, oauth, http-proxy, socks5 and ws features enabled, and k8s-openapi for the API types. That is the same client stack other Rust Kubernetes tooling uses, which means KDash authenticates the way kubectl does: it reads your kubeconfig, and the README's Docker instructions tell you to mount it, for example at /root/.kube/config inside the container.

The interface itself is built on ratatui with crossterm as the backend, both declared in Cargo.toml. Rendering is local. Data arrives over the Kubernetes API, and the ws feature in the kube dependency is what lets log streaming and watch-style updates work without polling everything.

Version 2.0 moved KDash from a read-only viewer to something that writes. The release notes list delete (Ctrl-d), edit in $EDITOR (e), rollout restart (r), previous container logs (p), scaling, and a node cordon plus CronJob suspend/resume/trigger action menu (m). Port-forwarding on a Pod or Service is bound to f, with Shift+F to list and stop active forwards. The notes state that forwards run in the background and are stopped when you quit KDash. Impactful actions are guarded by a confirmation prompt, which is the only thing standing between a keystroke and a deleted workload.

Installing KDash and opening your first cluster view

The README offers several routes depending on platform. On macOS and Linux, Homebrew is the documented default. Tapping the project's own tap and installing gives you a managed binary that brew can upgrade later.

brew tap kdash-rs/kdash
brew install kdash

On Windows the README recommends Scoop over Chocolatey, and says so directly: the Chocolatey package "may take a long while to become available after a release" because of validation. Scoop uses a separate bucket maintained by the project.

scoop bucket add kdash-bucket https://github.com/kdash-rs/scoop-kdash
scoop install kdash

If you already have a Rust toolchain, Cargo pulls the crate from crates.io. The README notes a fallback for k8s-openapi build problems.

cargo install kdash

# if you face issues with k8s-openapi crate try the below
cargo install --locked kdash

There is also a standalone install script that the README calls "the quickest way to grab the latest release binary without a package manager". It verifies the download against the published SHA-256 checksum and installs to ~/.local/bin by default, so no sudo is needed. Flags are passed through with sh -s --.

curl -fsSL https://raw.githubusercontent.com/kdash-rs/kdash/main/scripts/install.sh | sh

curl -fsSL https://raw.githubusercontent.com/kdash-rs/kdash/main/scripts/install.sh | sh -s -- --prefix ~/bin

Once installed, running kdash with no arguments uses your current kubeconfig context. The Makefile shows the same thing for a local build: cargo run, or make run, which formats, lints and then runs the app. Expect the first screen to be a cluster overview built from your current context, with namespaces and workloads listed and a hint bar at the bottom. If the screen is empty, the problem is almost always that the active context points somewhere you did not intend.

What KDash 2.x leaves out, and where it is the wrong tool

The repository carries a section titled "Limitations / Known issues", which tells you the maintainer considers this a real part of the project's surface rather than a footnote. That section is worth reading before you commit, because the shape of a TUI constrains what it can do.

KDash shows current state. It is not a metrics store. There is no history, no retention, no query language, and no alerting. If you need to know what a pod's memory looked like forty minutes ago, or you want a page when a deployment stops converging, KDash is the wrong layer and you should be looking at a monitoring system instead. The utilization view is a live picture, not a time series.

It is also a single-user tool. There is no shared configuration, no team view, no audit trail of who deleted what. Because actions run under your kubeconfig's identity, the blast radius of the delete and scale bindings is exactly your RBAC permissions. The confirmation prompt is a speed bump, not a permission system. On a cluster where you hold broad rights, Ctrl-d is a live key.

The README does not document rollback for the destructive actions it added in 2.0. Editing a resource in $EDITOR and applying it, or deleting one, is not described as reversible from inside KDash. Treat the editor as the real editor and the terminal as the viewport.

KDash versus K9s: same category, different bets

The obvious comparison is K9s, and the search data shows people make it. Both are terminal dashboards for Kubernetes with keyboard-driven navigation, both run as a local binary against your kubeconfig, and both let you act on resources rather than only watch them. The difference is in the bets each project makes.

KDash is written in Rust and distributed as a compiled binary with a comparatively small dependency list. The Cargo manifest is short enough to read in one sitting, and the project ships a musl-static build through a two-stage Dockerfile so the container image has no glibc dependency. That matters if you want to drop a single static binary onto a jump host or into a slim image. The Dockerfile also installs kubectl alongside the KDash binary, which is a reasonable hint about how the maintainer expects it to be used: as a companion to your existing tooling, not a replacement.

K9s has a much larger surface, with plugins and a broader set of resource views. KDash's README does not describe a plugin system at all. If extensibility is a requirement, that absence decides the question for you. If you want a fast, small, self-contained viewer and you are fine with the feature set the maintainer chose, KDash is the leaner option. Neither is a superset of the other, and the comparison is really about how much surface you want in a tool that can also delete things.

Maintenance, licence and the cost of upgrading

KDash is MIT licensed. In practice that means you can use, modify and redistribute it, including in commercial settings, provided the copyright notice and permission notice are preserved. The repository ships a LICENSE file and a SECURITY.md, and the crate metadata in Cargo.toml declares license = "MIT". This is not legal advice; check the licence text yourself if your organisation has rules about bundled dependencies.

The project is not archived. The last push to the default branch was on 2026-09-24, four days before this article, and releases v2.1.1, v2.1.0 and v2.0.2 landed between 2026-06-29 and 2026-07-22. That is a recent release cadence, and it is the only maintenance signal available here.

Upgrade cost depends entirely on how you installed it. Homebrew, Scoop, Chocolatey and AUR all have their own upgrade commands, and the README gives them. The install script supports --version to pin a specific release, which is the cleanest way to keep a fleet of jump hosts on the same build. The Docker image is tagged as deepu105/kdash, and the Makefile builds it with VERSION := latest by default, so a container-based rollout that relies on the default tag is not reproducible. Pin the tag.

The breakage risk is concentrated in the 2.0 release, which changed the interaction model by adding write actions and rebinding keys. Anyone upgrading from 1.x should re-read the keybindings rather than assume muscle memory still holds.

Editorial conclusion

Adopt KDash if you already live in a terminal, want a single binary with no cluster-side agent, and are comfortable that the same keybindings that browse resources also delete, scale and rollout-restart them. Skip it if you need historical metrics, alerting or a browser UI that non-engineers can use. Before rolling it out, check the Limitations section of the README, confirm your kubeconfig context and RBAC will not let a mistyped Ctrl-d land on production, and decide whether port-forwards running in the background until you quit fit your workflow.

Frequently asked questions

Official sources

1. kdash-rs/kdash on GitHub
2. License: MIT
3. Project website
4. README
5. Releases