Your cluster,
in plain sight.
Everything you do with a cluster — browse, diagnose, act — in one terminal console. Fast to navigate, faster to understand. Answers, not objects.
g d ↵ — three keys from anywhere to Deployments. No chords, no modifier keys, no memorizing.Every screen answers a question you actually asked.
An incident is three questions in a row. kute puts each answer on one screen, with the relevant events, conditions and related objects already gathered.
“Where is it broken?”
Unhealthy sorts first, healthy namespaces collapse — the whole cluster's problems on one screen.
“Why is it broken?”
Last termination on top — exit 137, OOMKilled, 4m ago — with logs that read across the restart.
“What changed?”
Rollouts, restarts and warnings from the last 30 minutes in one deduped, ordered stream.
One incident, start to finish.
A production namespace that looks fine. Then every namespace at once, and there is the crashlooping pod. Its detail screen opens on the reason, the logs carry on through the restart, and the timeline ties the whole thing to a rollout ten minutes earlier — recorded straight from kute --demo, unedited.
More recordings, and how to do each of these yourself, are in the guide.
Read it, understand it, change it.
Every kind of object works the same way, so the keys you learn on your first screen keep working on your last one — including on custom resources kute has never seen.
- Resource tablespods, deployments, nodes — every kind, one table
- Jump anywhereone key, fuzzy search across the cluster
- All-namespaces triageproblems first, healthy namespaces collapsed
- Cluster overviewcapacity, trouble, and what changed
- Your custom resourcesappear on their own, nothing to configure
- Pod & node detailopens on the reason, not the metadata
- Live logsfollow and filter, straight through restarts
- Events, dedupedwarnings first · ↵ goes to the object
- Incident timelinewhat changed in the last 30 minutes
- Who-canwhy a 403 happened, and who it would work for
- Scale & restartinline, one line, no modal in the way
- Set image & resourcestags from rollout history, limits beside real usage
- Labels, annotations, configwhat selects on them shown before you edit
- Exec & port-forwarda real shell; forwards stay up while you browse
- Bulk operationsfilter, mark, act on all of them at once
- Secret valuesmasked by default, re-masked when you leave
- Ingress & Gateway routingresolved to the backend that actually answers
- Helm releasesbrowse and roll back without the helm binary
- Flux CDthe source → reconciler chain, drift, reconcile and suspend
- YAML, and your editorread it here or edit it in
$EDITOR - Dark and lightfollows your terminal, or pick one
- Older terminals256-colour and ASCII fallbacks
- Update noticea quiet chip — kute never updates itself
Flux, read the way Flux actually works.
A generic CRD view asks one question — does Ready say true? — and on a Flux cluster the answer misleads. A reconciler mid-sync is working, not broken. A suspended one reports whatever it said before someone paused it. kute knows the difference, so a healthy GitOps cluster stops rendering as a column of red.
- The chain, on one screen. Each repository with the Kustomizations and HelmReleases it drives nested under it — the join you otherwise make in your head from two
kubectllists. - Why it failed, on the row. The condition message verbatim, exactly as Flux wrote it — and
↵resolves a failing health check to the workload it is waiting on. - Suspended stays in front of you. A paused Kustomization is the one quietly drifting from git, so it sorts above the healthy rows in amber instead of sinking in with them.
- The commit behind the change. In the incident timeline, a revision lands as its own row — the SHA, and the commit message when the cluster still knows it.
r reconciles, s suspends or resumes — plain API calls, so the flux binary is never required. kute never installs or bootstraps Flux, and never writes to your Git repository: that is CI's job.
Nothing happens that you didn't read first.
Every action prints the exact kubectl command before it runs. You can read it, copy it, or change your mind — and how much kute asks of you scales with how hard the thing is to undo.
kubectl scale deploy/nebula-qa --replicas=6y/N in the keybar, under the command — no modalYou decide which contexts count as production — kute never guesses from a name. Losing the connection mid-incident does not blank the screen: what it last saw stays readable, dimmed and stamped with its age. Secrets decode in memory only and re-mask when you leave. Every release is signed, too.
Install kute.
One binary, no cluster-side install. Or run kute --demo first and try it against a fake cluster.