arkade: a CLI marketplace for developer tools and Kubernetes apps

What arkade solves, and who ends up using it

Installing a working Kubernetes toolchain by hand is a sequence of small chores. Each tool has its own release page, its own archive format, its own install script, and its own idea about where the binary should live. arkade collapses that into a single binary that knows the download URL and the extraction rules for each entry in its catalog. The README states the project ships 204 CLIs and 53 Kubernetes apps, covering charts, manifests and installers.

The audience is narrow and easy to identify. Developers who rebuild laptops and VMs often, CI pipelines that need kubectl, kind, terraform or jq available before a job starts, and people learning Kubernetes who want ingress-nginx, Postgres or cert-manager running without reading a dozen install guides. The README frames the second group explicitly: the goal is to stop contending with dozens of README files just to set up a development stack.

It is a developer convenience layer, not a package manager. There is no dependency solver, no lockfile, and no notion of a system-wide package database. That distinction matters more than the marketing language around it.

How arkade resolves a download and runs an install

arkade is a Go program built on cobra, with the command tree under cmd/ and the logic under pkg/. Two subsystems do the real work.

The first is the get path. When you ask for a CLI, arkade looks up the tool in its catalog, determines the release asset that matches your operating system and architecture, downloads it, and places the binary on your PATH. The Makefile shows the release matrix the project itself builds for: linux/amd64, darwin, darwin/arm64, linux/arm with GOARM=6, linux/arm64, and windows/amd64. The same platform awareness is what lets arkade pick the right upstream asset for your machine.

The second is the apps path. Here arkade wraps Helm and kubectl. It either installs a chart with flags translated into chart values, or applies manifests directly. The README describes a deliberate design choice: instead of handing you a values.yaml, arkade exposes chart options as command-line flags, with --set available when you need to override something the flags do not cover.

There is also an OCI path. Release 0.11.124 added arkade oci login for registry authentication, and 0.11.125 added slicer-agent and signet shortcuts to oci install. That means arkade can pull tooling from OCI images, not only from GitHub release archives.

Installing arkade and installing your first tool

The repository ships a get.sh script at the top level, which is the install entry point the project provides for fetching the arkade binary itself. The README does not spell out the full bootstrap sequence in the excerpt available here, so check get.sh for the exact invocation rather than guessing at flags.

Once arkade is on your PATH, the first useful command is the catalog listing. Running it with no arguments prints the available commands and the app catalog, which is how you discover what is actually installable.

arkade

The next step is a CLI install. The README gives kubectl, kind, terraform and jq as the canonical examples, and describes the result as faster than waiting on apt-get install or brew update.

arkade get kubectl

For Kubernetes apps, the pattern is the same shape. You need a cluster and a kubeconfig first, and the README shows creating one before installing anything into it.

arkade install ingress-nginx

Removal is symmetric, which is worth knowing before you install something you might want to undo.

arkade uninstall ingress-nginx

CI is a first-class target. The README documents a GitHub Actions integration for installing CLIs during a workflow, so a runner can get its toolchain from arkade instead of a hand-maintained setup step.

The catalog is the product, and the catalog is the limit

arkade's value is entirely bound to its catalog. The README's own FAQ asks what is in scope for arkade get, which tells you the maintainers treat scope as a real question rather than an open-ended promise. If a tool is not in the catalog, arkade cannot help you, and you are back to the upstream install instructions.

That creates a specific failure mode for teams. A dev environment built on arkade is only reproducible as long as every tool you need is covered. The moment one dependency falls outside the catalog, your setup script grows a manual branch, and the consistency guarantee weakens. Nothing in the README or the repository files reviewed here describes a lockfile pinning catalog entries to exact versions, so an install performed today and the same install performed next month can resolve to different upstream releases.

The Kubernetes apps side has a comparable boundary. Installing a chart with flags is convenient, but the flags are a curated subset of what the chart exposes. The README acknowledges this directly by offering --set as the escape hatch. Once you are passing several --set values, you have reconstructed a values file in a less readable form, and the convenience argument starts to invert.

There is also a compounding feature the README documents, where one app's output feeds another, such as getting a self-hosted TLS registry with authentication or a public IP for a private cluster. Useful, and also the point where an install stops being a single command and becomes an orchestration you should script and review.

Where arkade sits next to Helm

The README's FAQ addresses the comparison head-on with a section titled How does arkade compare to helm. The practical difference is what each tool considers its unit of work.

Helm's unit is a chart and a values file. You declare the desired state in YAML, commit it, review it in a pull request, and upgrade it with a versioned release record. That is the right shape for anything that lives in production, because the diff between two states is visible to a reviewer.

arkade's unit is a command with flags. You type arkade install ingress-nginx with the options you want, and it runs. That is the right shape for a laptop or an ephemeral cluster, where the setup is disposable and the speed matters more than the audit trail. The README's own FAQ asks whether arkade is suitable for production use, and the honest reading is that arkade is a convenience wrapper that drives Helm and kubectl underneath, not a replacement for a release process.

The README also documents a chart maintenance path: bumping Helm chart versions and verifying and upgrading images inside a chart. That is closer to a maintenance utility than an installer, and it is the part of the tool most likely to be useful to someone who already has a Helm-based workflow rather than someone avoiding one.

Maintenance, upgrades and what the MIT licence covers

The repository is not archived, and the last push was on 2026-09-21. Release cadence is visible in the recent tags: 0.11.124 on 2026-08-22, 0.11.125 on 2026-08-28, and 0.11.126 on 2026-08-29. Those are small, focused releases rather than large version jumps, which is consistent with a project that adds catalog entries and adjusts install behaviour incrementally.

Upgrading arkade is cheap because it is a single static Go binary. The Makefile builds with CGO_ENABLED=0, so there is no libc coupling to worry about, and the dist target cross-compiles for every supported platform. Replacing the binary is the whole upgrade.

The cost that does not go away is catalog drift. Every entry points at an upstream release URL, and upstream projects move, rename assets, or change archive layouts. The repository has a dedicated e2e-url-checker workflow, which indicates the maintainers treat link rot as a known operational concern rather than a one-time problem. If you depend on a specific tool through arkade, that dependency inherits the maintenance burden of the catalog entry.

arkade itself is MIT licensed, per the LICENSE file and the badge in the README. That covers arkade's own code. It does not cover the tools and charts you install with it. Each upstream project carries its own licence, and installing a chart into a cluster does not change the licence terms that apply to that software. Check the upstream licence for anything you ship, particularly for charts that pull container images with separate terms.

Editorial conclusion

Use arkade if you rebuild dev machines, CI runners or throwaway clusters and you are tired of pasting install snippets from a dozen README files. Skip it if you need a managed, auditable deployment path for production workloads, or if your team has standardised on Helm values files that reviewers read. Before adopting it, verify the licence and provenance of each upstream tool it fetches, and confirm that the specific app you need is in the catalog rather than assuming the 53 entries cover it.

Frequently asked questions

Official sources

1. alexellis/arkade on GitHub
2. License: MIT
3. Project website
4. README
5. Releases