# Krew: the package manager for kubectl plugins

> Krew gives kubectl plugins a discovery index, an install path and an upgrade mechanism, so the commands you already have to remember separately can be installed the way you install anything else.

**kubernetes-sigs/krew** — 📦 Find and install kubectl plugins

- Repository: https://github.com/kubernetes-sigs/krew
- Website: https://krew.sigs.k8s.io
- Stars: 7,041 · Forks: 414
- Language: Go
- License: Apache-2.0
- Published: 2026-10-07 · Updated: 2026-10-07 · Language: en
- Canonical page: https://hysenlabs.com/projects/kubernetes-sigs-krew

## Packages that are kubectl subcommands

kubectl discovers plugins by name. A binary named `kubectl-foo` becomes `kubectl foo`, and that convention predates Krew by years. What Krew adds is the layer most people were missing: a shared index where plugins are described, where they can be found by keyword, and from which they are installed and upgraded with a single command rather than a curl line copied from a blog post.

The README states the audience twice, which is a useful design hint. For kubectl users, Krew makes plugins discoverable and manageable in a consistent way. For plugin authors, it handles packaging and distribution across platforms and makes a plugin findable. One binary serves both sides of that transaction, and the second half is why the index has the shape it does.

The comparison the README offers is apt rather than decorative: it puts Krew next to apt, dnf and brew. Those are all tools whose hard part is not installing a program, it is knowing which programs exist, whether the version you have is current, and what you installed in the first place.

## Bug reports belong to one of three repositories

The community section is the most useful paragraph in the README because it routes problems to the right place, and the three destinations are genuinely different.

A problem with Krew itself goes to this repository. A problem with a particular plugin's installation or its upgrade goes to the krew-index repository, because that is where the plugin's manifest, platform list and version metadata live. A problem with a plugin's actual behaviour goes to the repository hosting that plugin's source code.

That split is the honest consequence of Krew's architecture. It downloads an artifact and runs it; it does not build it and it does not review it. When something goes wrong, the useful question is which of the three layers broke, and the README hands you the routing table rather than leaving you to guess. For a team adopting plugins across many tools, this also means your upgrade failures may land in a repository you have never looked at, which is worth knowing before you pin versions across a fleet.

## Three releases in three years, and still on version zero

The release history is short and spread out. v0.4.4 was published in July 2023. v0.4.5 followed in March 2025, a gap of about twenty months. v0.5.0 arrived in February 2026. The last push to the repository was on 2026-09-18, so work is happening between releases rather than the project being abandoned.

The project is still at 0.x after more than a decade of kubectl plugin use, which tells you something about how the maintainers read their own stability guarantee. For a tool that installs binaries, the compatibility surface is the installed set rather than your code, so a conservative version number costs nothing and buys a lot.

The release notes are also worth reading as a pattern rather than a list. Each one points at the installation instructions for that tag and then lists per-platform archives, and every note says in substance that you should follow the installation instructions rather than use the artifacts directly. What those artifacts are is clear from their names. For v0.5.0 the set is krew-darwin_amd64, krew-darwin_arm64, krew-linux_amd64 and krew-linux_arm, each shipped as a tar.gz with a matching .sha256 file next to it.

The presence of that linux_arm archive alongside linux_amd64 and darwin_arm64 is a small time signal. 32-bit ARM is still being built, even though most machines running kubectl today are arm64.

## The README admits its own architecture document is out of date

The contributor documentation list is unusually candid. `PLUGIN_LIFECYCLE.md` is described as not necessarily up to date, but still a good idea of how Krew works under the covers. `KREW_ARCHITECTURE.md` is described as not up to date, without qualification.

Read those two labels together and they tell you something specific about this project: the behaviour people actually depend on is the install and upgrade path, and the project's own sense is that the written model of that path has drifted from the code. For a tool whose whole job is mutating your local environment, that is a real gap, and the honest mitigation is the plugin lifecycle document, which is the one covering the behaviour you depend on. The logo document, for what it is worth, is current.

One more small thing: the default branch here is `master`, not `main`. That is not a signal about maintenance, but it does mean clone commands copied from documentation elsewhere may need adjusting, and the README's own contribution links are relative so they do not have that problem.

## What the dependency list says about the interface

Krew's manifest is short enough to read in full, and it describes a conventional command line tool:

```go
module sigs.k8s.io/krew

go 1.25
```

The direct dependencies explain the feature set. `spf13/cobra` and `spf13/pflag` provide the command and flag handling that every subcommand needs. `sahilm/fuzzy` is the fuzzy matching library behind searching the index, which is the one dependency that explains a user-facing decision. `fatih/color` and `mattn/go-isatty` handle coloured output that respects whether the terminal supports it, and `git-lfs/go-netrc` exists to read credentials from a netrc file, which matters for anyone behind a proxy or on a machine with private git hosts.

Two Kubernetes libraries, `apimachinery` and `client-go`, are pulled in at 0.34.1. That is worth noting rather than worrying about: Krew is reading index and release metadata, not talking to an API server, so the dependency is there for types and conventions rather than for a client you will configure.

The tree is organised the way you would expect, with `cmd/` for entry points, `internal/` and `pkg/` for logic, `integration_test/` for end to end coverage of the install path, `hack/` for scripts and `site/` plus a Netlify configuration for the documentation and index pages.

## Conclusion

Krew solved a small problem completely, and the shape of the project reflects that. The tool is a single Go binary built on cobra, the index lives in its own repository, and the plugin itself is whatever the index entry points at, which means the interesting failure modes belong to other people's code. If you are evaluating it, the decision is not technical so much as about your habits: whether your team wants one command for listing and upgrading plugins instead of a directory of shell aliases. Read the quickstart on krew.sigs.k8s.io, then treat the plugin lifecycle document as the authoritative description of what upgrade actually does, since the README itself flags it as only approximately current.

## FAQ

### How to install Krew for kubectl?

The README deliberately does not carry the command. Installation is documented on krew.sigs.k8s.io with a dedicated quickstart page, and the release notes for every version point readers at those instructions for their tag rather than at the artifacts. What the releases do publish is a per-platform archive plus a sha256 file for each of darwin amd64, darwin arm64, linux amd64 and linux arm, and the notes explicitly recommend using the documented installation instead of downloading those archives directly.

### What problem does Krew solve that copying a shell script does not?

kubectl has supported external subcommands for years, so any plugin can be run by putting a binary named after it on your PATH. What you lose is discovery, versioning and cleanup. Krew adds an index you can search, per-plugin platform metadata, and commands to list, upgrade and remove what you have installed, which is the same reason apt and brew exist for operating systems.

### Where should I report a problem with a kubectl plugin?

It depends on which layer is broken. Problems with Krew itself go to the Krew repository. Problems with a plugin's installation or upgrade go to the krew-index repository, which holds the plugin's manifest and version metadata. Problems with how a plugin behaves go to the repository that hosts that plugin's source code. The README spells out all three routes.

### Is Krew stable enough to use in a managed environment?

The project is still published as version 0.x, most recently v0.5.0 in February 2026, with work continuing in the repository afterwards. It ships archives for darwin amd64, darwin arm64, linux amd64 and linux arm, each with a checksum file. If you manage developer tooling centrally, the plugin lifecycle document in the docs directory is the place to check what an upgrade actually does, and the README describes it as approximate rather than authoritative.

### How many kubectl plugins are available through Krew?

The README states that over 200 kubectl plugins are available on Krew, and links the plugin list on the project site. The index itself lives in a separate repository, which is also where you report problems with a specific plugin's installation or upgrades rather than with Krew.

## Sources

- [kubernetes-sigs/krew on GitHub](https://github.com/kubernetes-sigs/krew)
- [License: Apache-2.0](https://github.com/kubernetes-sigs/krew/blob/master/LICENSE)
- [Project website](https://krew.sigs.k8s.io)
- [README](https://github.com/kubernetes-sigs/krew/blob/master/README.md)
- [Releases](https://github.com/kubernetes-sigs/krew/releases)

---

Hysen Labs editorial analysis, written from the project's own repository and release notes. Cite the canonical page: https://hysenlabs.com/projects/kubernetes-sigs-krew