Komodor Helm Dashboard: a web UI for the Helm releases on a cluster

Standalone binary versus Helm plugin, and why the difference matters

The README says that since version 1.0 the recommended install is a standalone binary that does not require Helm or kubectl to be installed. You download the release package for your platform, unpack it, and run the `dashboard` binary.

The plugin path still exists and is documented in the same section:

helm plugin install https://github.com/komodorio/helm-dashboard.git

helm plugin update dashboard

helm plugin uninstall dashboard

Here is the contradiction worth pausing on. The feature list claims the tool does not require Helm or kubectl installed, and the standalone section repeats it. Two paragraphs later, the plugin section states that your machine needs working `helm` and `kubectl` commands, with Helm 3.4.0 or newer required. Both are true and they describe different modes, but the README presents the first statement as a property of the tool rather than of one install method.

Once installed as a plugin, the command is the same either way. `helm dashboard` starts a local web server and opens the UI in a new browser tab, then hangs until you stop it from either the command line or the web interface. The plugin form of that command requires the plugin; the standalone form is just `dashboard`.

Binding, ports, namespaces, and the precedence order

The configuration surface is small and defaults to being safe. By default the web server is only reachable locally. You change that with the `HD_BIND` environment variable or a `--bind` flag, and the README states the precedence explicitly: the flag wins over the environment variable, which wins over the default of `localhost`.

`0.0.0.0` binds all IPv4 addresses and `[::0]` all IPv6. If port 8080 is taken there is a `--port` flag. `--namespace` limits operations to one namespace or several separated by commas, which is the flag you want in a multi-tenant cluster where showing every release would be both noisy and a small disclosure risk. `--no-browser` suppresses the tab that would otherwise open, and `--verbose` turns on debug logging.

That combination makes the container case straightforward. The Dockerfile's entrypoint hardcodes three of these decisions:

ENTRYPOINT ["/bin/helm-dashboard", "--no-browser", "--bind=0.0.0.0", "--port=8080"]

Inside a pod there is no browser to open and no loopback-only audience, so binding to all interfaces on 8080 is the correct default there, and it is exactly what the image does without being asked.

Analytics are on unless you turn them off

The README carries a disclaimer about user analytics, framed as being for the sake of improving project quality. Collection is done through DataDog RUM and Heap Analytics, described as anonymous data with no sensitive information, and it can be disabled with the `--no-analytics` option.

Both halves of that sentence matter, and only one of them is verifiable from the repository. That no sensitive information is sent is an assertion in the README. That the option exists is a fact, since it is documented as a flag and there is no other way to express the intent. For a tool whose job is to display manifests, revisions and cluster state, the sensible reading is that the telemetry covers page interactions rather than manifest contents, but the README does not enumerate the event properties, so treat that as an assumption rather than a guarantee.

The default being on is the part to make a deliberate choice about. If your policy is that no data leaves the environment without review, pass `--no-analytics` on day one rather than discovering the flag later during an audit.

What the feature list promises and where it defers to FEATURES.md

The README's capability list is short and each item is concrete: see installed charts and their revision history, see a manifest diff of past revisions, browse the Kubernetes resources a chart produces, roll back or upgrade with the diff visible, integrate with problem scanners, switch between clusters, and run either locally or inside the cluster. Then it says all features are discovered via the features overview page, which is `FEATURES.md` at the root of the repository.

That deferral is where the interesting material lives. The manifest diff combined with rollback is the part that goes beyond a read-only viewer, because it turns a rollback into a reviewable action: you see what will change, then you change it. The problem scanner integration is the other item with real leverage, since it turns a tool you open when something is already wrong into one that can point at the problem.

The project is explicit about its provenance in a way worth repeating. It is part of Komodor's stated goal of helping Kubernetes users navigate and troubleshoot clusters, and the README states plainly that Helm Dashboard is not an official project of the Helm team. That matters for how you read the roadmap: this is a company maintaining a useful free tool that sits alongside its commercial Kubernetes product, not a community project under the Helm umbrella.

Building from source, and the Go and TypeScript split

GitHub reports this repository as a TypeScript project, which is accurate about where the interface lives and misleading about where the work is. The tree has `frontend/` and `package-lock.json` at the root for the UI, and `main.go`, `go.mod`, and `pkg/` for a Go backend. The `go.mod` declares the module as `github.com/komodorio/helm-dashboard/v2`, requires Go 1.25.0, and depends directly on `helm.sh/helm/v3 v3.20.2` plus the Kubernetes client libraries at v0.35.1. Embedding Helm and the Kubernetes client is what lets the standalone binary work without those tools installed.

Local development needs Golang and Node.js, and the frontend has to be built before the backend:

cd frontend && npm run build && cd ..
go build -o bin/dashboard .

`make build` wraps both. Afterwards you can run `npm run dev` from the `frontend` directory for Vite hot reload on the interface while the Go binary serves it. There is a separate `make debug` target that runs the built binary with `DEBUG=1` set.

The Dockerfile shows how the two halves ship together, building the UI in a Node stage, copying the compiled assets into the Go build context, and running the result from an Alpine image. The multi-stage build is why the released binary is self-contained rather than a wrapper around a Node runtime. For plugin development from a checkout, `helm plugin install .` creates a symlink, so a rebuild does not require reinstalling.

Release cadence and project health

The version history is short and tells a fair amount. v2.1.0 landed on 2026-03-17 and was a large maintenance release: adding a uid for identification, a bulk package version bump, fixes to queries, mutations and JSON parsing, prettier and eslint configuration work, and enabling recommended type checking. The tailwindcss class fixes and the DropDown key fix in that same release are the kind of change that comes from a toolchain upgrade rather than from feature requests.

v2.1.1 on 2026-03-27 fixed two user-visible bugs: using unique installed package keys in the frontend, and a manifest diff that showed all resources as recreated. That second one matters more than its size suggests, since a diff which marks everything as changed destroys the value of having a diff.

v2.1.3 on 2026-08-10 is a single CI fix, restoring all tracked files before goreleaser runs. A release tagged purely on a build pipeline repair is a good sign about the pipeline and a reminder that the binary release path is automated rather than hand-assembled.

The last push was 2026-09-12, and open issues stand at 21 against 5,759 stars. Support runs through a Komodor Slack community for general questions and GitHub issues for real bugs, which is a reasonable split, though it does mean the issue tracker is where a bug report should go rather than Slack.

Editorial conclusion

Helm Dashboard is genuinely good at one thing that the Helm command line makes clumsy: comparing what a chart looks like now against what it looked like three revisions ago, and rolling back with the diff visible while you decide. The standalone binary is the mode to start with, since it needs nothing else on the machine and binds to localhost by default. Two things to know before you deploy it anywhere shared. The project is maintained by Komodor as part of its own commercial Kubernetes tooling and says plainly that it is not an official Helm project, so its roadmap serves that business first. And it collects anonymous analytics through DataDog RUM and Heap Analytics unless you pass --no-analytics, which is worth deciding on deliberately rather than by default. The features overview at FEATURES.md is where the actual capability list lives; the README is the install guide.

Frequently asked questions

Official sources

1. Issues
2. komodorio/helm-dashboard on GitHub
3. License: Apache-2.0
4. README
5. Releases