radar: a single Go binary that depends on all of Cilium

Thirty seconds, and it talks to your cluster before you read the security section

The fastest path is one line: fetch a script over the network, hand it to a shell, and run the tool.

curl -fsSL https://get.radarhq.io | sh && kubectl radar

The file explains the mechanics without highlighting them. The script writes to a system binary directory unless you say otherwise, and that directory usually needs root, so the thirty seconds includes privilege you have not been asked about. The directory is created if missing and has to be on the search path for either the bare command or the plugin form to resolve. Then the same line runs the tool, which opens a browser and connects to the cluster API through your kubeconfig. All of that happens before a reader reaches the security section, which sits sixth in the file's own contents list. The two install scripts are committed to the repository, which is better than the usual arrangement, so the one thing missing is not the script but a description of what it does.

No account and no cloud, and a cloud status command that reads a secret

The pitch is a single binary with no account required, free forever, and cluster data that stays on your machine with no cloud sync. Then the usage section documents a command that reports on a hosted service, and the paragraph under it says that live status for it is obtained using a token held in a Kubernetes secret in the cluster. So there is a cloud component, and reaching it means a token that lives in your cluster and is read by the local tool. Two things are done well and belong next to that. The file says the command reports this without printing the token, and it says that if the secret or the remote service is unavailable the local diagnostics still run. The other item is separate. Opting in to usage reporting is off by default, and when on it sends counts plus what the file calls coarse cluster facts, which it then enumerates: your Kubernetes version, your platform, a node-count range, and which integrations it has detected. That is environment fingerprinting, and it is the one place the privacy claim needs a footnote.

The CLI prints tokens, and the styling rule is what says so

Two separate sentences in the usage section confirm that credentials reach the terminal. The first is about colour: in an interactive terminal the tool uses restrained status colours, and it says that URLs, tokens and suggested commands remain unstyled. The carve-out only makes sense if those three are being printed. The second is about the cloud status command, which reports configuration while promising not to print the connection token. So the file twice tells you that tokens are present in the output and once tells you the one place they are deliberately withheld. Set against that, the tool honours a no-colour environment variable and defers to its own help output over the documentation table, which are two signs of care about the terminal. The gap is that no section says where the tokens come from or how long they live.

scoop install radar, unqualified, right after adding a bucket

The Windows instructions add a bucket under one alias and then install a package with no bucket qualifier. Unqualified means the package manager resolves it against its own default bucket list, which does not include the one you just added. So the documented Windows path can install a different program with the same short name, or fail, and the fix is the qualified form that the Homebrew instructions do use. The naming across package managers is where the confusion comes from. The plugin manager installs something called radar, the Homebrew formula is called kubectl-radar, and the desktop application is called radar-desktop on two managers. Four of the six routes also create a bare command alongside the plugin form, and that bare name is short and common enough to shadow something you already had. The file is candid that the other two routes do not create it.

A single binary that depends on an entire network plugin

The description ends with everything in one Go binary, and the module file is the interesting document. Among roughly forty direct requirements are a full copy of a container network plugin project, a desktop application framework, the model context protocol software development kit, a common expression language engine, the Helm library, an OpenID Connect client, a D-Bus binding, a pseudo-terminal library, three Prometheus client libraries, eight Kubernetes modules all aligned to one version, and a pure-Go SQLite driver. So the binary is single and the dependency surface is not small, and the file never explains the choice. Two of those entries deserve a second look on their own. The expression engine is what the access-control and view layer presumably evaluates, and the protocol kit is the evidence that the assistant feature is real rather than a plan.

The main package is called explorer, and a subdirectory is its own module

The build file compiles a command directory called explorer and writes the output to a binary called radar. So the product, the module, the image and the command all use one name and the source layout uses another. Alongside that, the module file requires the project's own subdirectory as a separate module at a placeholder version of zero, which is why the container build copies that subdirectory before downloading modules: the dependency is satisfied from the tree. The JavaScript side is smaller and stranger. The root manifest declares two workspaces, one override that pins an HTML sanitiser to an exact version, and exactly one development dependency, which is the TypeScript compiler installed under an alias with a floating range. There is no script in the root manifest at all, because the build script lives in the web workspace, and there is no bundler, linter or test runner in the file the repository shows.

A third of the build targets manage seven demo clusters

The build file declares fifty-seven targets and twenty-one of them set up, tear down or inspect demo clusters, one set for a container network plugin, one for a batch scheduler, one for a GPU ecosystem, one for a cost tool, and so on. That is a deliberate investment in making the tool demonstrable against real ecosystems, and it is worth more than it costs. The rest of the file is where the sharp edges are. The in-cluster test deploy has a default test image pointing at a personal container registry path with a feature-branch tag rather than a published release, so the out-of-the-box behaviour of that target is to push to and run somebody's development build. The version string comes from the tag description with a dirty marker appended, and the build flags here omit the size-trimming flags the container build passes, so a local binary and a released one are built differently. The development port default is set in the build file and never appears in the documentation. And the generated test image file is written by a line that stops mid-path.

A CNCF logo at the root, and two registry manifests for the assistant

The repository carries two logo assets side by side, one for the application and one carrying the foundation of the cloud native project's mark. Nothing in the file claims a relationship with that foundation, and foundation marks are governed by a trademark policy rather than by the code licence, so this one is worth an owner looking at rather than a reader. The two files that do correspond to a real integration are the registry manifests at the root, one for a model-context-protocol directory and one for the server registry, which together are what makes the assistant feature installable by other tools. Three other root directories are undocumented: one holds agent configuration, one holds a design token set, and one is the air reload file that pairs with the watch targets in the build file. The project is careful about several things and silent about these.

Editorial conclusion

radar fits an operator who wants cluster state on their own machine rather than in a vendor's dashboard, and it fits an assistant-driven workflow only once you have decided what that assistant may reach. Verify four things before you install it. Read what installing actually does, because the quick path fetches a script and writes to a system directory, and the tool then talks to the cluster API the moment it runs. Read what opting in to usage reporting sends, because the list includes your Kubernetes version, platform and node-count range rather than counts alone. Decide the cluster's view, since the default namespace filter is everything and the scope is whatever your identity can see. And check the assistant's reach, because the project ships a protocol server for exactly that purpose and says nothing about limiting it.

Frequently asked questions

Official sources

1. License: Apache-2.0
2. Project website
3. README
4. Releases
5. skyhook-io/radar on GitHub