Kite: a self-hosted Kubernetes dashboard that bundles multi-cluster ops, RBAC and an AI assistant

What Kite is for, and who ends up running it

Kite targets the moment a team stops having one cluster. Once there are three or four, the work of checking a deployment, reading a pod log, confirming a Helm release and answering "who changed this" is spread across kubeconfig contexts and terminal tabs. Kite's answer is a single workspace that holds several clusters at once and layers access control on top. The README frames it as "All your clusters. One workspace." and lists four areas: observe, operate, govern, work with AI.

The audience is the platform or infrastructure engineer who already administers clusters and wants a shared UI rather than a personal one. Governance features point the same way: OAuth, LDAP, local accounts, MFA and passkey login, RBAC with per-cluster permissions, and audit logs for resource changes. A single developer with one kind cluster is not the target. The default chart values are explicitly labelled for evaluation, which tells you the project expects an operator to make production decisions before real traffic arrives.

How the pieces fit: Go server, TypeScript UI, agents and a database

The repository is a Go module at the root (module github.com/zxh326/kite, go 1.26.0) with the frontend under ui/. main.go, app.go, routes.go and static.go sit at the top level, and the compiled UI is embedded into the binary, which is why the Dockerfile builds the frontend in a node:24-alpine stage and copies the result into the Go build before compiling a single static binary on gcr.io/distroless/static.

Cluster connectivity has two paths. When Kite runs inside the cluster it manages, the setup flow offers an in-cluster connection type. For remote clusters, go.mod pulls in github.com/rancher/remotedialer (with a replace directive pointing at a fork), which is the tunnelling library behind the documented Kite Cluster Agent. That agent model matters: it is how a dashboard outside the cluster reaches a cluster without you opening its API server to the internet.

State lives in a database. The Docker example passes DB_DSN=/data/db.sqlite, and go.mod carries gorm.io/driver/mysql, gorm.io/driver/postgres and github.com/glebarez/sqlite, so SQLite, MySQL and PostgreSQL are all supported back ends. For Kubernetes work the server uses client-go and kubectl libraries plus helm.sh/helm/v4 for release management, and Prometheus metrics come through prometheus/client_golang. The AI assistant is wired to both github.com/anthropics/anthropic-sdk-go and github.com/openai/openai-go, so two provider families are in scope. Authentication libraries are equally explicit: go-ldap for directory login, go-webauthn for passkeys, and golang-jwt for sessions.

Installing Kite from the OCI chart and connecting a first cluster

The README's quick start installs from the OCI registry into a dedicated namespace. This is the shortest path to a running instance.

helm install kite oci://ghcr.io/kite-org/charts/kite \
  --namespace kite-system \
  --create-namespace

Then forward the service to your machine. The chart exposes port 8080.

kubectl port-forward --namespace kite-system svc/kite 8080:8080

Open http://localhost:8080, create the first administrator, and follow the setup flow. When Kite runs inside the cluster it manages, the README says to choose the in-cluster connection type, which avoids distributing credentials for that cluster.

The README attaches an explicit warning to this path: the default chart values are for evaluation. Before production you are told to enable persistent storage or configure an external database, replace the default encryption key, and review the chart's cluster-wide RBAC permissions. Treat those as three separate tasks, not one checkbox.

If you prefer containers over Helm, the Docker route mounts a data directory and points the database at it:

mkdir -p data
docker run -d --name kite \
  -p 8080:8080 \
  -v "$(pwd)/data:/data" \
  -e DB_DSN=/data/db.sqlite \
  ghcr.io/kite-org/kite:latest

The environment variable is DB_DSN and the container listens on 8080. There is also a standalone manifest at deploy/install.yaml, which the README says stores application data inside the container unless you add persistent storage, and which grants its service account cluster-admin. That grant is the single most important line in the deployment documentation.

Building from source requires Go 1.26, Node.js ^20.19.0 or >=22.12.0, pnpm and Make:

git clone https://github.com/kite-org/kite.git
cd kite
make deps
make build
./kite

Where Kite gets in the way, and when it is the wrong tool

The cluster-admin service account on the standalone manifest is a real constraint, not a footnote. The README itself instructs you to review and restrict those permissions before using the manifest outside a test environment. If your security model forbids a dashboard holding cluster-admin, the manifest is off the table and you are configuring the Helm chart's RBAC by hand.

Persistence is the second trap. The manifest keeps application data inside the container. A restart of that pod can take your users, audit history and cluster connections with it. The Docker example is safer only because it mounts a volume, and the chart defaults are still described as evaluation-grade.

The AI assistant is narrower than the marketing line suggests. The README states that write operations are reviewed and confirmed before execution and that the assistant respects the current user's RBAC permissions. That is a sensible design, but it means the assistant cannot do anything the logged-in user could not do by hand, and it inherits every gap in your RBAC configuration. It is also provider-bound: the code depends on the Anthropic and OpenAI SDKs, so an air-gapped environment with no route to either API gets no assistant at all.

Finally, Kite is a dashboard. It does not reconcile desired state, it does not replace GitOps, and it does not act when nobody is looking at it. If your problem is drift or unattended remediation, a controller is the right shape of tool and Kite is not.

Kite against kubectl, Lens and Headlamp

The honest comparison is not against kubectl, which remains the fastest path for a single command and needs no server to be running. The comparison is against other dashboards, and the difference is where the state lives.

Lens and Headlamp are desktop-style clients: the cluster credentials sit on the engineer's laptop, and access follows whoever holds the kubeconfig. Kite inverts that. It is a server you host, with its own user store, its own OAuth and LDAP integration, per-cluster permissions and audit logs. The trade-off is direct: you gain centralized governance and a shared URL, and you take on running a stateful service, protecting its database, and managing the encryption key the README tells you to replace.

Against Headlamp specifically, the split is also about scope. Headlamp is a Kubernetes UI you can extend with plugins. Kite ships a wider built-in surface: Helm release management, browser-based pod, node and kubectl terminals, a built-in Kube Proxy for reaching pods and services, global search, and the AI assistant. More built-in surface means less assembly, and also more code inside the trust boundary of a component that holds cluster-admin.

If your team already has a GitOps pipeline and a metrics stack, the marginal value of Kite is the shared operational view and the governance layer, not the resource editing. If you have neither, Kite is doing a lot of jobs at once and each one deserves scrutiny before you depend on it.

Licence, maintenance and the cost of upgrading

Kite is licensed under Apache-2.0, which permits commercial use, modification and redistribution provided the licence and notices are preserved. That is a permissive licence with no copyleft obligation on your own code. It says nothing about the operational risk of running a component with cluster-admin, and it is not legal advice; check your own compliance process.

The project is not archived, and the last push was on 2026-09-10. Releases are frequent: v0.15.1 on 2026-09-08, v0.15.0 on 2026-08-15, v0.14.1 on 2026-07-22. That cadence has a cost. The version is still 0.x, so minor releases can carry schema or configuration changes, and the database back end means an upgrade is not just a new container image: you are migrating state. The README does not document rollback, so a downgrade path is something you would have to establish yourself before upgrading a production instance.

Budget for the upgrade ritual. Snapshot the database, read the release notes for the version you are moving to, and re-check the chart values, because the README's production checklist (persistent storage or external database, replaced encryption key, reviewed RBAC) is exactly the set of things a chart upgrade can quietly reset.

Editorial conclusion

Adopt Kite if you run several clusters and want one self-hosted pane for resources, Helm releases, Prometheus metrics and an AI assistant that inherits the current user's RBAC permissions. Skip it if you only need a thin read-only view of one cluster, or if you cannot accept a service account with cluster-admin, which the standalone manifest grants. Before rollout, verify three things: that you have replaced the default encryption key, that you have pointed DB_DSN at persistent storage or an external database instead of the container filesystem, and that the chart's cluster-wide RBAC permissions match what your teams should actually be able to do. Until the cluster-admin grant in deploy/install.yaml is replaced with a scoped role, that manifest belongs in a test cluster and nowhere else.

Frequently asked questions

Official sources

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