# kubedb/cli is the kubectl plugin behind KubeDB's day to day database work

> The repository builds kubectl-dba, the kubectl plugin for the KubeDB database operator, in Go, with cobra commands over the Kubernetes API and the KubeDB apimachinery types. The README is short and points everything else at kubedb.com, and the licence is the AppsCode Community License rather than an OSI one.

**kubedb/cli** — `kubectl` plugin for KubeDB

- Repository: https://github.com/kubedb/cli
- Website: https://kubedb.com
- Stars: 733 · Forks: 58
- Language: Go
- License: NOASSERTION
- Published: 2026-10-21 · Updated: 2026-10-21 · Language: en
- Canonical page: https://hysenlabs.com/projects/kubedb-cli

## A plugin for one operator's custom resources

KubeDB is a Kubernetes operator for databases. The CLI repository holds the command line companion to it: a kubectl plugin, in the sense that it is invoked as a kubectl subcommand and follows the plugin naming convention.

The README itself is three paragraphs plus four links. It identifies the project as a `kubectl` plugin for KubeDB by AppsCode, points installation at the KubeDB setup guide, points usage at the KubeDB guides, and points contributors at the contribution guidelines. Support goes through the AppsCode contact form and their Twitter account, and bugs and feature requests are filed as issues on the kubedb/project repository rather than on this one.

That last detail is a useful signal about the division of labour. The plugin is one component in a wider product that is documented centrally, and this repository is the code rather than the manual. Anyone evaluating it should read the docs site first and treat the repository as the implementation.

The intended audience is Kubernetes operators who run databases through KubeDB and want the same declarative resources to be manageable from a terminal. The project language is Go, the homepage is kubedb.com, and the repository is not archived with the last push on 2026-10-12.

It is worth being clear about what this is not. There is no database client here in the sense of a tool that connects to a running database over SQL. The whole surface of the project is Kubernetes shaped.

## Cobra over the Kubernetes API and the KubeDB types

The go.mod file describes the architecture by its dependencies. The module is kubedb.dev/cli and it targets Go 1.26.0.

Command parsing is handled by spf13/cobra, and the Kubernetes plumbing comes from the usual set: k8s.io/cli-runtime for the plugin machinery that lets a binary act as a kubectl subcommand, k8s.io/client-go for the API client, k8s.io/api and k8s.io/apimachinery for the resource types, k8s.io/component-base and k8s.io/kubectl for shared components. The version skew between k8s.io/kubectl at v0.32.3 and the rest of the Kubernetes libraries at v0.34.3 is visible in the file.

The KubeDB specific pieces are the ones that make this more than a generic Kubernetes tool. kubedb.dev/apimachinery provides the custom resource definitions for the databases the operator manages, and kubedb.dev/db-client-go is the client for talking to them. kubeops.dev/petset appears as a dependency, which is the operator toolkit for working with sets of pods, and kmodules.xyz/cert-manager-util is there for the TLS certificates that operators of this kind hand out.

There is also a monitoring dependency, github.com/prometheus/client_golang, and a MySQL driver, github.com/go-sql-driver/mysql, which suggests the plugin is not only manipulating custom resources but is capable of talking to a database server for some operations. Other supporting libraries include github.com/fatih/camelcase for name conversion, gomodules.xyz/logs for logging, and sigs.k8s.io/yaml for manifest handling, alongside sigs.k8s.io/controller-runtime and a set of AppsCode and gomodules.xyz libraries.

## The Makefile names the binary and the target platforms

The build is driven by a Makefile in the repository root, and a few of its lines tell you what you get.

The binary is called kubectl-dba, which is the naming a kubectl plugin needs to be discovered:

```bash
GO_PKG   := kubedb.dev
REPO     := $(notdir $(shell pwd))
BIN      := kubectl-dba
COMPRESS ?= no
```

The version is derived from Git rather than typed in. The Makefile captures the branch, the exact tag, the commit hash and the commit timestamp, and then picks a strategy: if an exact tag exists the tag becomes the version, otherwise a release- branch name is used, and otherwise it falls back to the commit hash with a dirty marker for an unclean tree.

Cross platform output is explicit. The container platforms are linux/amd64, linux/arm and linux/arm64:

```bash
DOCKER_PLATFORMS := linux/amd64 linux/arm linux/arm64
BIN_PLATFORMS    := $(DOCKER_PLATFORMS) windows/amd64 darwin/amd64 darwin/arm64
```

So the released binaries cover the three Linux architectures plus Windows on amd64 and macOS on both amd64 and arm64. That combination is worth noting because it means a developer on an Apple Silicon laptop and a CI runner on a Linux arm node can both install the plugin from the same release train.

The source layout mirrors the Go convention with SRC_PKGS := cmd pkg and a separate hack/gendocs directory included in the source directories, which is where the command reference is generated from. The shell is set to /bin/bash -o pipefail, so the build assumes bash rather than a POSIX shell.

## Vendored dependencies and a generated docs pipeline

The repository layout is unusual in one visible way: there is a vendor directory at the top level. Alongside it sit cmd, pkg, docs, hack and the usual Go files, go.mod and go.sum.

Vendoring means the dependencies are committed to the repository, so a build does not have to reach the module proxy. For a project whose dependency list pulls in Kubernetes, cert-manager, controller-runtime and Prometheus libraries, that is a large tree, and it makes the build reproducible at the cost of a repository that changes when dependencies do.

The docs directory and the hack/gendocs directory point at a second pattern. Rather than writing command reference pages by hand, the Makefile treats hack/gendocs as source, which means the command documentation is derived from the cobra command definitions. That is how a project with a large number of subcommands keeps its reference in step with the code, and it is the reason the CLI repository can be almost empty of prose while still producing a reference.

The linting setup is visible too, with a .golangci.yml at the root, and the repository carries AGENTS.md, CLAUDE.md, a DCO file and a CHANGELOG.md. The DCO matters for contributors, because it means contributions are made under a Developer Certificate of Origin rather than a copyright assignment, and the CHANGELOG is the place to look for what changed in a release since the README says nothing about it.

## The AppsCode Community License is not an OSI licence

The licence is the thing to read carefully. Every source file in the repository carries the same header, and the Makefile spells it out: Licensed under the AppsCode Community License 1.0.0, with a link to the licence text in the appscode/licenses repository, and the usual warranty disclaimer.

That is a custom licence, and GitHub cannot classify it as one of the standard licences, which is why the licence field points at the LICENSE.md file instead. The LICENSE.md file at the root holds the actual terms.

What this means practically is worth saying plainly, because it is a licensing fact rather than legal advice: this is not Apache 2.0, not MIT and not GPL, and it does not grant you the rights those licences grant. If you are evaluating the plugin for a product, read the AppsCode Community License 1.0.0 text directly, because the obligations it places on a commercial user, and on a user who distributes the binary, are the ones that determine whether you can adopt it. The same applies to the other AppsCode components you would pull in.

For a team evaluating the plugin as an internal tool, the licence question is usually the simpler one, but it is still a question, and the answer is a URL away in the source header of every file.

## Maintenance, releases and the shape of the release train

The repository is not archived, and the last push was on 2026-10-12. The recent release list is instructive because it shows a train that includes release candidates: v0.68.0 published on 2026-10-11, v0.67.0-rc.2 on 2026-08-26 and v0.67.0-rc.0 on 2026-08-14.

Two things follow. First, the version numbers track the KubeDB release train, since the go.mod pulls kubedb.dev/apimachinery at v0.68.0, matching the v0.68.0 CLI release. The CLI and the operator move together, and the plugin has to be upgraded in step with the custom resource definitions it understands.

Second, the presence of release candidates in the recent history means the project publishes pre-releases for the next minor version, so a stable pin is a deliberate choice and the candidates are there for people who want them early.

The CHANGELOG.md at the root is where the substance is, because the README contains no release notes at all. For anyone tracking this project, the combination to watch is the changelog, the go.mod dependency versions, and the KubeDB documentation site, since a change in the operator's custom resources is what would force a plugin upgrade.

## Where kubectl-dba is the wrong tool

The first wrong case is using it as a database client. The plugin works against the operator's custom resources and the Kubernetes API. If what you want is to run a query against a running Postgres or MySQL instance, this is the wrong binary, and the fact that a MySQL driver appears among the dependencies does not change that.

The second wrong case is not running KubeDB. The plugin exists to manage databases that the KubeDB operator manages. If your databases are deployed by Helm charts you wrote, by a different operator, or by hand, then there are no KubeDB custom resources for kubectl-dba to act on, and the tool has nothing to do.

The third is a policy decision about the licence and the support model. The source is under a custom community licence, the plugin is versioned in lockstep with the operator, and the README routes bug reports to a separate project repository. A team that needs a long lived, independently maintained database tooling component should weigh that before wiring the plugin into a runbook.

The realistic alternative, and it is not a competitor product, is to work with the custom resources directly: apply the YAML, read status with kubectl get, and manage the objects with the standard tooling. The plugin's value is convenience and the ergonomics of the KubeDB model, not new capability. If the ergonomics are not worth the extra dependency and the licence conditions, plain kubectl on the same resources does the job.

## Conclusion

Adopt kubectl-dba if you already run the KubeDB operator and want to work with the database custom resources from the command line rather than from a web console or from raw YAML. Do not adopt it as a database client, because it is a plugin for one operator's custom resources and not a way to connect to a running database. Before you build it, read the setup guide at kubedb.com/docs/latest/setup/ and note that the source is under the AppsCode Community License 1.0.0, that the Makefile produces a binary named kubectl-dba, and that the release train currently includes release candidates, with v0.68.0 published on 2026-10-11.

## FAQ

### What is kubedb/cli and what binary does it build?

It is the kubectl plugin for KubeDB by AppsCode, written in Go. The Makefile sets the binary name to kubectl-dba, which is what makes it work as a kubectl subcommand, and it is built for linux, windows and darwin on amd64 and arm64.

### How do I install kubectl-dba?

The README does not give plugin installation steps of its own, it points to the KubeDB setup guide at kubedb.com/docs/latest/setup/. Usage is documented in the KubeDB guides, and contributions are covered at kubedb.com/docs/latest/welcome/contributing/.

### Which Kubernetes and KubeDB libraries does the CLI depend on?

The go.mod requires k8s.io/cli-runtime, client-go, api, apimachinery and component-base at v0.34.3, plus kubedb.dev/apimachinery at v0.68.0 and kubedb.dev/db-client-go at v0.23.0, along with cert-manager utilities, controller-runtime and Prometheus client libraries.

### What licence is kubedb/cli under?

The source headers and the Makefile state the AppsCode Community License 1.0.0, with the terms in the LICENSE.md file at the root. It is a custom licence rather than one of the standard open source licences, so the text itself defines what you may do with it.

### Where should I report a bug in the KubeDB CLI?

The README asks you to file issues for bugs and feature requests in the kubedb/project repository rather than in the CLI repository itself. General support goes through the AppsCode contact form, and product announcements through their Twitter account.

## Sources

- [Issues](https://github.com/kubedb/cli/issues)
- [kubedb/cli on GitHub](https://github.com/kubedb/cli)
- [Project website](https://kubedb.com)
- [README](https://github.com/kubedb/cli/blob/master/README.md)
- [Releases](https://github.com/kubedb/cli/releases)

---

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