Install kute.

macOS and Linux

The install script picks the right build for your machine, checks the download against its published checksum, and — if you have cosign installed — its signature too.

Or with Homebrew

The script installs to /usr/local/bin. Set KUTE_INSTALL_DIR to put the binary somewhere else — ~/.local/bin, say, if you would rather not use sudo — or KUTE_VERSION to pin a specific release instead of taking the newest.

Windows

In PowerShell:

Or with Scoop

kute draws with Unicode glyphs and 24-bit colour, so Windows Terminal gives you the best result. It runs in the older console host too, in a plainer palette.

Download it yourself

Every release ships six builds — Linux, macOS and Windows, each for x86-64 and arm64 — on the releases page. Unpack the archive, put kute somewhere on your PATH, and that is the whole installation.

Every archive is signed, carries a build provenance attestation, and ships a software bill of materials. Verifying a download walks through checking all three by hand — worth doing once if you are putting this on a machine that touches production.

What you need

• A kubeconfig — the same one kubectl uses. kute reads $KUBECONFIG, then ~/.kube/config, and uses in-cluster credentials when it runs inside a pod.
• Your own permissions, nothing more. kute reads with your credentials. Read access to a namespace is enough to be useful; anything you are not allowed to list shows up as a permission card explaining what was refused, not as an empty table.
• Nothing on the cluster. There is no agent, operator or CRD to install. Uninstalling is deleting a file.
• A terminal — including one over SSH. A 24-bit-colour terminal looks best; kute falls back to a 256-colour palette and ASCII glyphs where it has to.
• kubectl, for three things only — opening a shell in a container, editing an object in your $EDITOR, and a shell on a node. Everything else talks to the API directly.

Your first run

Start with the demo. It is the whole app against a fake cluster held in memory — real screens, real keys, real failure states, nothing to connect to and nothing you can break:

Then point it at a real cluster. Plain kute opens on your current context; --context and -n override that:

Press ? for the keys that work where you are, and g to go anywhere. The guide covers the rest.

Updating and uninstalling

kute checks for a new release about once a day and shows a quiet chip in the header when there is one. U opens what changed, with the exact upgrade command for the way you installed it. It never updates itself.

To uninstall: remove the binary (brew uninstall kute, scoop uninstall kute, or delete it from /usr/local/bin). kute keeps two small files of its own, both safe to delete — ~/.config/kute/config.yaml if you made one, and the remembered contexts and namespaces under ~/.local/state/kute/.

Common problems

kute: command not found

The binary landed somewhere that is not on your PATH — most often after setting KUTE_INSTALL_DIR. Check where it went, then add that directory to your PATH in your shell's startup file.

macOS says it cannot check the developer

That is Gatekeeper reacting to a binary you downloaded by hand rather than through Homebrew. Installing with brew or the install script avoids it entirely; if you have already downloaded one, clear the quarantine flag with xattr -d com.apple.quarantine ./kute — after verifying it, which is a better check than Gatekeeper's anyway.

The install script says cosign was not found

Not a failure. The download is still checked against its published checksum; the signature check is the extra step that needs cosign present. Install cosign and re-run if you want both.

Outbound requests are restricted where you work

The once-a-day release check is the only request kute makes that is not to your cluster. Turn it off with update: check: false in ~/.config/kute/config.yaml.

Something else

The guide's troubleshooting section covers connection failures, permission errors and cloud-provider credential plugins. If it is a bug, an issue is the right place.