KOTS treats a Kubernetes app as something you install, license and upgrade

Two halves: a kubectl plugin and an in-cluster console

KOTS is the collective set of tools for distributing and managing Kubernetes Off-The-Shelf software, and it splits cleanly into a client side binary and an in-cluster application.

The client side is the Kots CLI, described as a general purpose client side binary for configuring and building dynamic Kubernetes manifests, and it is a kubectl plugin, so it runs as a kubectl subcommand. Its second job is to act as the bootstrapper for the in-cluster Kubernetes application Admin Console, kotsadm.

The admin console is where the management work happens, and the README enumerates it: license verification, configuration, updates, image renaming, version controlling changes, and deployment. It also handles additional KOTS tasks, specifically running preflight checks and performing support bundle analysis.

That division of labour is the design idea worth understanding. The CLI runs on an administrator's laptop, with cluster credentials, and it can do things a console pod cannot, such as rewriting image references to point at a mirror the customer can reach. The console then runs inside the customer's cluster, where it holds the configuration values and the app version, and it can talk back to the vendor. A vendor that only had a Helm chart would have to rebuild all of that, which is the gap KOTS fills.

The project is Go, the licence field on the repository says Apache-2.0, and the last push was on 2026-10-19 with release v1.132.0 tagged on 2026-09-19.

MinIO is on by default and it brings the AGPL question

The single most consequential operational detail in the README is about storage, and it is not obvious from the name of the project.

By default, KOTS leverages MinIO as a standalone object store instance to store application archives and support bundles. All communication between KOTS and the MinIO object store is limited to a REST API released under the Apache 2.0 licence, and KOTS has not modified the MinIO source code. The catch follows: the use of MinIO for this purpose is currently governed by the GNU AGPLv3 licence in the MinIO project itself.

So the integration is a clean REST boundary with no source modification, but the component being deployed is copyleft licensed. For a vendor shipping software into customer clusters, that is a question worth answering before the first install, not after.

There are two documented ways out. An optional install flag, --with-minio=false, is available for new KOTS installs and for upgrades from existing versions, and a disableS3 option exists in the KOTS add-on for kURL clusters, usable for new installs or upgrades. Embedded Cluster v2 does not deploy MinIO at all, and its Admin Console stores this data in rqlite instead.

The licences in play are otherwise friendly to redistribution. KOTS itself is Apache-2.0, and the kotsadm admin console is the in-cluster part of the same project.

make dev starts a local cluster and two admin console endpoints

The development path is short and self contained. The requirements are macOS, OrbStack with Kubernetes enabled, and Homebrew. You clone the repository, then run make dev from the root directory.

git clone https://github.com/replicatedhq/kots.git
cd kots

make dev

Once the environment is up, the admin console is reachable two ways: directly at http://localhost:30808, or through the kURL proxy at http://localhost:30880. The second path matters when you are debugging the proxy behaviour that real customers hit, since the proxy is what fronts the console in a deployed cluster.

The default make dev deploys a local MinIO instance named kotsadm-minio, and it is used for two jobs: the object store for application archives and support bundles, and the snapshot storage backend.

To exercise the Local Volume Provider path for snapshots, the environment is started with WITH_MINIO set to false.

WITH_MINIO=false make dev

That creates the kotsadm-confg ConfigMap with minio-enabled-snapshots set to "false", so KOTS uses the LVP path for HostPath and NFS snapshot destinations. The MinIO StatefulSet is still deployed in that mode, because the object store role remains.

The README is careful about the gap between this toggle and production, and the note is worth repeating: the dev environment remains a Deployment with S3 environment variables, while a kots install --with-minio=false installation in production deploys KOTS as a StatefulSet with a kotsadmdata PersistentVolume and uses BlobStore on the local filesystem instead of MinIO.

The Go module and Makefile show how the project is tested

The go.mod names the module github.com/replicatedhq/kots and pins Go 1.26.8. The dependency list is long and tells you what a KOTS installation actually has to do: it talks to object storage on Google Cloud Storage and Azure, to container registries through the AWS and Docker registry clients, to GitHub through go-github, to Kubernetes through the distribution libraries, and to databases including Postgres and SQLite. It also pulls in sealed-secrets, which is how a licence key or other sensitive value can be stored in the cluster, and promptui for interactive prompts in the CLI.

The Makefile shows the shape of the test suite. The unit test target runs go test over ./pkg/... and ./cmd/... with a coverage profile, and a separate ci-test target adds ./integration/... . There is a pact-consumer target for contract tests, an e2e target that delegates to a subdirectory Makefile, and a target that builds a kots-integration binary.

Cross compilation is explicit, with separate targets for linux amd64 and linux arm64, and a kots target that creates the web/dist directory, touches a placeholder README and then builds the binary from cmd/kots. The Makefile also pins the Helm version to 4.1.3 with recorded SHA256 checksums for amd64 and arm64, and pins the MinIO, rqlite, dex and LVP image tags, which is the kind of dependency pinning that makes a supply chain review tractable.

The repository also carries a .grype.yaml for vulnerability scanning, a securebuild/ directory, a design/ and proposals/ directory, and a migrations/ directory for the admin console database.

Every release ships a signed SBOM you can check with Cosign

The software bill of materials section is short but concrete. Signed SBOMs for the KOTS Go dependencies are included in each release, and the README gives the Cosign command to validate the signature.

cosign verify-blob --key sbom/key.pub --bundle sbom/kots-sbom.tgz.bundle sbom/kots-sbom.tgz

The verification uses a public key from the repository and a bundle that carries the signature alongside the tarball, so a customer can confirm that the SBOM matches what was published rather than trusting a checksum in a release note.

That is worth a note in the context of what KOTS does. A vendor using KOTS is shipping a controller into someone else's cluster, and the controller runs with real permissions. A verifiable SBOM attached to the release is the kind of artefact that shortens a security review, and it is included by default rather than added later.

The releases themselves are frequent. Recent tags include v1.132.0 on 2026-09-19, v1.131.8 on 2026-09-08 and v1.131.7 on 2026-09-04, which is a patch-level release roughly every few days for a project that also has to coordinate with the Kubernetes releases it supports.

Where KOTS is the wrong tool

The first boundary is the vendor relationship. License verification is listed as a core admin console task, and image renaming and version controlling of changes are as well, which means KOTS is built for a company that sells software and controls the version a customer runs. If you are deploying one application to one cluster for your own team, a plain Helm chart and a values file do the same job with far less machinery.

The second boundary is platform support. The README states that KOTS supports OSX, including Apple Silicon arm64, and Linux platforms. There is no Windows support listed, which for a client side CLI that is often the one machine a corporate administrator has is a genuine constraint.

The third is the operational surface. A KOTS install puts a StatefulSet, an admin console web application, a database, an object store and a set of migrations into a cluster the customer owns. Teams that have strong policies about what may run in their clusters will need to justify all of that, and the --with-minio=false path reduces but does not remove the footprint.

The alternative worth comparing against is packaging the application as a Helm chart with a wrapper chart for configuration, which has no license verification, no admin console and no support bundle analysis. The trade is that the vendor then handles upgrades, configuration drift and customer support by hand, which is usually more expensive than the components KOTS installs.

Editorial conclusion

Adopt KOTS if you are a software vendor who must install a licensed application into customer managed clusters and needs licensing, configuration, image renaming and update control in one flow, since the kots CLI and kotsadm cover both the client side and in-cluster halves. Do not adopt it for a single internal deployment with no vendor relationship, because the licensing verification and admin console machinery is the bulk of what it does. Verify first whether you need the default MinIO object store, because KOTS has not modified the MinIO source and MinIO is governed by the GNU AGPLv3 licence, so if that is a concern for your distribution, plan around the --with-minio=false install flag from the start.

Frequently asked questions

Official sources

1. License: Apache-2.0
2. Project website
3. README
4. Releases
5. replicatedhq/kots on GitHub