Kubie: per-shell Kubernetes context switching with split config files

What Kubie solves that kubectx and kubens do not

kubectx and kubens change the current context and namespace by rewriting the kubeconfig file. Every shell that reads that file sees the change. If you have a production terminal open and a staging terminal open, switching one moves both. The k on prompt script works around this by exporting KUBECONFIG to a temporary file, but it is a shell function, not a program, and it does not manage the files for you.

Kubie makes the shell the unit of isolation. The README describes it as offering context switching, namespace switching and prompt modification "in a way that makes each shell independent from others". It also loads contexts from multiple files, so a config split across ~/.kube/config and ~/.kube/configs/*.yaml is presented as one list. That second part matters more than it sounds: split configs are common once you have more than a handful of clusters, and tools that read only KUBECONFIG force you to merge them by hand.

The intended user is someone who already lives in a terminal and juggles clusters. If you switch context once a day, kubectx is smaller and does the job.

How the isolation actually works: kubie exec, kubie export and the config globs

Kubie is a Rust binary built with clap for argument parsing and skim for the selectable menus that appear when you run kubie ctx or kubie ns with no argument. The interesting mechanism is kubie export, which "prints the path to an isolated config file for a context and namespace". That generated file is what the spawned shell points KUBECONFIG at, which is why two terminals can hold different contexts without touching ~/.kube/config.

Context discovery is driven by globs in ~/.kube/kubie.yaml. The documented defaults include ~/.kube/config, ~/.kube/*.yml, ~/.kube/*.yaml, ~/.kube/configs/*.yml, ~/.kube/configs/*.yaml, ~/.kube/kubie/*.yml and ~/.kube/kubie/*.yaml. Kubie's own config file is always excluded, so it cannot accidentally appear as a context source.

For automation there is kubie exec, which runs a command in a given context and namespace without spawning an interactive shell. It accepts a wildcard in place of the context, in which case the command runs in every matching context, and the -e flag makes it fail early if any invocation returns a non-zero exit code. The behavior.print_context_in_exec setting controls the CONTEXT => header, with auto printing it only when stdout is a TTY. That default is sensible for piping, but if you parse kubie exec output in a script you should set it to never rather than rely on the TTY check.

Installing Kubie on Ubuntu, macOS or from cargo

The README lists several install paths. On macOS, Homebrew and MacPorts both carry it. On Arch Linux it is in the extra repository. For everything else, including Ubuntu, there is a release binary on the GitHub releases page that you download and chmod +x, or a cargo install that builds from crates.io.

The cargo route needs a Rust toolchain first. The README points at rustup.rs for that, then gives a single command:

cargo install kubie

On Ubuntu without a Rust toolchain, the release binary is the shorter path. The README says to download it from the releases page and reminds you to chmod +x the file.

Once installed, the first real use is switching context in the current shell:

kubie ctx

With no argument this opens a selectable menu of contexts. Picking one either switches the current shell, or spawns a new shell if you are not already inside a kubie shell. To jump straight to a context and namespace in one step, the README documents kubie ctx <context> -n <namespace>.

Shell completion is a separate step. For bash or zsh, the README gives this line for your ~/.bashrc or ~/.zshrc:

source <(kubie generate-completion)

Fish users run kubie generate-completion fish | source instead. The README defers to the clap_complete docs for the full list of supported shells, which is where to look if yours is not bash, zsh or fish.

Namespace validation is the setting that will bite you

By default behavior.validate_namespaces is true, which means Kubie checks that a namespace exists with kubectl get namespaces before switching to it. That is a friendly default for a cluster where you have broad read access. It is a wall in a cluster where you do not have permission to list namespaces, which is common with tightly scoped RBAC roles or with per-namespace service accounts.

The README acknowledges this directly: set it to false if you do not have the right to list namespaces. The middle option, partial, changes the matching behavior rather than disabling the check. With partial, if you run kubie ns <namespace> and there is no exact match, exactly one partial match switches immediately, and multiple partial matches open a selection menu. That is convenient and also slightly surprising: a typo that happens to be a substring of one real namespace will silently take you there.

There is a second, quieter limitation. The README's top of file carries an important notice pointing at issue #385 regarding the future of Kubie development. Whatever that issue concludes, it is the first thing to read before building a workflow around the tool. The repository is not archived and the last push was on 2026-09-19, with v0.28.0 released on 2026-05-25, so the code is moving. The notice is about direction, not abandonment.

Kubie versus Kubeswitch and plain kubectx

The closest alternative in the search data is Kubeswitch, and the difference is in how contexts are stored. Kubeswitch is built around a store of kubeconfig files that it discovers and indexes, and it offers a switcher plus a shell hook. Kubie instead reads the globs you declare in ~/.kube/kubie.yaml and generates an isolated config per context and namespace via kubie export. If your kubeconfigs already live in a directory layout you like, Kubie's glob list is a thin layer over it. If you want the tool to own discovery and indexing, Kubeswitch takes that job.

Against kubectx and kubens, the split is simpler. Those two mutate the shared kubeconfig, so the switch is global. Kubie's switch is per shell. If you have never wanted two contexts open at once, kubectx is a smaller dependency and you already know how it behaves.

One more difference worth noting: kubie exec and kubie lint have no equivalent in kubectx. kubie lint scans k8s config files for issues, and kubie exec runs a command across every context matched by a wildcard. Those two commands are the reason to install Kubie even if you keep kubectx around.

Licence, upgrade path and what kubie update does

Kubie is licensed under Zlib, a permissive licence that is shorter and looser than MIT in its wording. It is not a copyleft licence, so there is no obligation to publish changes you make. The Cargo.toml declares license = "Zlib" and the repository carries a LICENSE file. As always, read the licence text yourself rather than treating this as legal advice.

Upgrades depend on how you installed it. Homebrew, MacPorts, pacman and Nix users upgrade through their package manager. Cargo users re-run cargo install kubie. The README also documents a self-update path:

kubie update

The README says this checks the latest kubie version and updates your local installation if needed. That command is behind the update feature, which is on by default in Cargo.toml and pulls in attohttpc for the HTTP call. If you build with --no-default-features to drop the HTTP dependency, kubie update will not be available and you are back to your package manager. That is the trade-off worth knowing before you pick an install method: the release binary and cargo default both carry the updater, and a minimal build does not.

Editorial conclusion

Adopt Kubie if you keep several clusters open at once and want each terminal to hold its own context and namespace, especially if your kubeconfig is split across ~/.kube/configs or ~/.kube/kubie. Do not adopt it if you want a single global context for every shell, or if you cannot list namespaces in the clusters you use and do not want to set validate_namespaces to false. Before rolling it out, run kubie lint against your existing config files and check the state of issue #385, which the README links regarding the future of Kubie development.

Frequently asked questions

Official sources

1. kubie-org/kubie on GitHub
2. License: Zlib
3. Project website
4. README
5. Releases