kubewall: a single-binary Kubernetes dashboard for multi-cluster work

The gap kubewall fills for people who juggle several clusters

The default answer to "I want a Kubernetes UI" is the official dashboard, which you install into a cluster and reach through a proxy or an ingress. That model assumes one cluster per installation and a service account you are willing to create inside it. kubewall inverts the assumption. It is a local process that reads your kubeconfig, so the clusters it shows are the ones you already have credentials for, and nothing is deployed into them. The README frames the target user directly: DevOps teams that lose time switching between tools. The second audience is less obvious. Anyone debugging an on-premises or air-gapped cluster, where installing a dashboard means a change request, gets a UI by downloading one file. The third is the solo operator who wants port forwarding and log tailing in a browser instead of a terminal multiplexer full of kubectl commands.

One Go process, a browser client, and your kubeconfig as the source of truth

The repository splits into backend/ (Go) and client/ (TypeScript), with a single release artifact per platform. The binary serves the compiled frontend and a backend that holds the Kubernetes client connections. Credentials come from your kubeconfig rather than from an in-cluster service account, which is why the Docker example mounts ~/.kube into the container. Live updates use server-sent events: the README warns that over plain HTTP/2 SSE hits a limit on the number of open connections, and recommends HTTPS for that reason. The flags expose the client-side throttling knobs directly, --k8s-client-qps (default 100) and --k8s-client-burst (default 200), so a dashboard watching many resources does not have to look like a runaway controller to the API server. That is a small detail, but it tells you the authors expect the tool to be pointed at clusters where the API server is already busy.

Installing kubewall and loading your first cluster

The README lists Docker, Helm, Homebrew, Snap, Arch, Winget, Scoop and plain binaries. The fastest path on a workstation is the binary or Homebrew, because both use the kubeconfig already on the machine. After installation the README says the UI is reachable at http://localhost:7080.

brew install --cask kubewall/tap/kubewall

If you prefer a container, the README mounts the kubeconfig and a persistent volume for kubewall's own state. Note that this runs with host networking, so the port is the host's port.

docker run --network host -v kubewall:/.kubewall -v ~/.kube:/.kube ghcr.io/kubewall/kubewall:latest

For a shared or on-premises deployment the Helm chart is the documented route. The README states that the chart runs kubewall on port 8443 with self-signed certificates.

helm install kubewall oci://ghcr.io/kubewall/charts/kubewall -n kubewall-system --create-namespace

Before pointing it at anything, check which contexts you are about to expose. kubewall reads the kubeconfig it is given, so the flag set below is the same one you would use to keep it off the network entirely.

kubewall --listen 127.0.0.1:7080 --no-open-browser

The --listen default is 127.0.0.1:7080, and --no-open-browser stops the binary from launching your default browser. For TLS, the README documents --certFile and --keyFile, and suggests generating a local certificate with mkcert:

mkcert kubewall.test localhost 127.0.0.1 ::1
kubewall --certFile=kubewall.test+3.pem --keyFile=kubewall.test+3-key.pem

Once the process is up, the browser shows the clusters present in your kubeconfig. From there the documented actions are the ones you would expect: browse pods, services and ConfigMaps, read manifests and logs, tail aggregated logs across pods and containers, scale deployments, restart pods, perform rollout restarts, apply manifests, and open port forwards to in-cluster services.

Where kubewall stops being the right tool

The single-binary design is also its main limitation. Because kubewall authenticates with the kubeconfig it is handed, it inherits exactly those permissions. There is no per-user identity layer described in the README, no mention of an audit trail, and no documented multi-tenant model. If five engineers need different levels of access, a dashboard that runs as whoever started it does not give you that. The README also does not document rollback of an applied manifest, so the "apply" button is a one-way action from the UI's point of view. The AI features deserve the same caution: they are optional integrations with OpenAI, Claude, Gemini, DeepSeek, OpenRouter, Ollama, Qwen or LMStudio, and any hosted provider means cluster data leaves your machine, which sits awkwardly next to the "privacy by default" claim unless you point the integration at a local model such as Ollama or LMStudio. Finally, the release history is honest about maturity: the latest tag at the time of writing is v0.0.23, and a 0.0.x version number is a reasonable signal that interfaces and behavior can still move between releases.

kubewall against the official Kubernetes dashboard

The official dashboard is deployed into the cluster and reached through kubectl proxy or an ingress, and it is designed around a service account and its RBAC. kubewall runs outside the cluster, uses your kubeconfig, and needs no in-cluster footprint, which is the whole point of the Docker example mounting ~/.kube. The trade-off follows from that: the official dashboard gives you an access-control boundary you can hand to a team, while kubewall gives you a personal or shared view that is only as restricted as the credentials behind it. If your requirement is "give the platform team a URL and let them log in as themselves", the official dashboard model fits better. If your requirement is "let me see six clusters from my laptop without touching any of them", kubewall is the shorter path.

Licence, versioning and what an upgrade actually costs

kubewall is Apache-2.0, which permits commercial use, modification and redistribution provided the licence and notices are preserved. That is permissive enough for internal deployment at a company, but the usual caveat applies: if you fork it and ship it to customers, the notice obligations are yours to handle, and this is not legal advice. Upgrades are cheap in the binary case, since the release assets are self-contained tarballs and zips per platform and the Homebrew, Snap, Winget and Scoop channels track releases. The Helm path is the one to think about, because the chart pins a version and the README documents a self-signed certificate on port 8443, so a chart bump can change both the image and the serving configuration. The last push to the repository was on 2026-09-05, and v0.0.23 was tagged on 2026-09-01, so the project is moving, but the 0.0.x line means you should read the release notes before each jump rather than assuming compatibility.

Editorial conclusion

Adopt kubewall if you run several clusters from one workstation and want a browser UI that reads your existing kubeconfig without an in-cluster agent. Skip it if you need a hardened, multi-tenant dashboard with per-user RBAC, or if you cannot expose port 7080 or 8443 to the people who need it. Before rolling it out, verify what your kubeconfig grants, confirm the release cadence suits you (v0.0.23 landed on 2026-09-01), and decide whether the AI features should be left unconfigured.

Frequently asked questions

Official sources

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