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

The problem Kite targets: too many clusters, too many separate consoles

Most teams running Kubernetes at any scale end up with a stack of disconnected views. One terminal for kubectl, one browser tab for a Helm release list, another for Prometheus graphs, and a spreadsheet or identity provider for who is allowed to touch which cluster. Kite's stated goal is to collapse that into one workspace: the README describes it as a workspace for multi-cluster operations, observability, access control, and AI-assisted troubleshooting, with the tagline "All your clusters. One workspace." The audience is therefore platform or infrastructure engineers who already operate more than one cluster and who are tired of stitching together access control per cluster. It is not aimed at someone running a single hobby cluster, where kubectl and a dashboard addon cover the same ground with far less surface area.

What the workspace actually contains

The README groups features under four verbs. Observe covers per-cluster Prometheus integrations for CPU, memory and network usage, plus streaming and filtering of pod logs and inspection of events, conditions and related resources. Operate covers core Kubernetes resources, CRDs and Helm releases across multiple clusters, live YAML editing, scaling and restarting workloads, and browser-based pod, node and kubectl terminals, with global search and a built-in Kube Proxy for reaching pods and services. Govern covers OAuth, LDAP, local accounts, MFA and passkey login, with RBAC and per-cluster permissions backed by audit logs for resource changes. Work with AI covers an assistant that can inspect resources, logs and Prometheus metrics, and that asks for confirmation before write operations while respecting the current user's RBAC permissions. Those four groups are the product's whole claim. The interesting part is the governance layer: per-cluster permissions plus audit logs plus an assistant constrained by the same permissions is a design where the AI feature is not a separate privileged path into the cluster.

Architecture and data flow visible in the repository

Kite is a TypeScript project that builds with Go 1.26, Node.js ^20.19.0 or >=22.12.0, pnpm and Make, which tells you the backend is a compiled Go binary and the interface is a Node-built frontend, with Make orchestrating both. The database is configurable: the Docker example sets DB_DSN=/data/db.sqlite, so SQLite is the default store, and the Helm notes tell you to "enable persistent storage or configure an external database" before production. Clusters are connected in two ways. When Kite runs inside the cluster it manages, the setup flow offers an in-cluster connection type, which is the simplest path. For other clusters there is a documented Kite Cluster Agent, listed in the documentation table alongside Helm management. The README does not describe the agent's transport or authentication in the material available here, so treat that as something to read up on before designing a multi-cluster topology. What is clear is the shape: one Kite deployment holds application state in a database, and it reaches out to clusters either through its own in-cluster credentials or through agents.

Getting it running: Helm, Docker and the manifest

The quickest path in the README is the OCI chart. Install into a dedicated namespace with helm install kite oci://ghcr.io/kite-org/charts/kite --namespace kite-system --create-namespace, then kubectl port-forward --namespace kite-system svc/kite 8080:8080 and open http://localhost:8080 to create the first administrator and connect a cluster. The Docker route is explicit about state: mkdir -p data, then docker run -d --name kite -p 8080:8080 -v "$(pwd)/data:/data" -e DB_DSN=/data/db.sqlite ghcr.io/kite-org/kite:latest. There is also a standalone manifest, kubectl apply -f https://raw.githubusercontent.com/kite-org/kite/main/deploy/install.yaml, followed by a port-forward on svc/kite in the kube-system namespace. The README is unusually direct about that manifest: it stores application data inside the container unless you add persistent storage, and it grants its service account cluster-admin. Building from source is four commands: make deps, make build, then ./kite. Config keys named in the material are DB_DSN for the database and the chart's values file, which the README points at for storage, encryption key and RBAC settings.

The evaluation defaults are the main risk, and the README says so

The strongest signal in this repository is the warning block above the installation guide. The default chart values are described as intended for evaluation, and the README lists what to change before production: enable persistent storage or configure an external database, replace the default encryption key, and review the chart's cluster-wide RBAC permissions. That is three separate problems. A default encryption key protects whatever the database holds, which includes credentials for connected clusters and user records. A container-local database means the first pod restart discards your configuration. Cluster-wide RBAC means the dashboard's own service account can read and write across the cluster, so anyone who compromises the Kite login inherits that reach. The manifest is blunter still: cluster-admin. None of this makes Kite unusual for a self-hosted dashboard, but it does mean the port-forward-and-click path in the quick start is a demo, not a deployment. A second limitation follows from the feature list itself: Kite is an operator's tool. If your requirement is a read-only window for developers who must never scale or delete anything, the browser terminals, live YAML editing and restart actions are capabilities you would have to switch off through RBAC configuration you write yourself, and the README does not spell out a read-only profile.

Where Kite sits against kubectl and a plain dashboard

The obvious alternative is kubectl plus the upstream Kubernetes dashboard, or a read-only observability front end such as Grafana for metrics with kubectl for everything else. The difference is where governance lives. With kubectl, authorization is the cluster's own RBAC and authentication is whatever your kubeconfig or identity provider gives you; there is no separate user directory, no per-cluster permission model inside a dashboard, and no audit log of dashboard actions, because there are no dashboard actions. Kite moves that layer into the application: OAuth, LDAP, local accounts, MFA and passkeys on one side, RBAC with per-cluster permissions and audit logs on the other. That is the trade. You gain a single sign-on surface and a record of who changed what through the UI, and you take on a second authorization system that must be kept in step with the cluster's own, plus a database that now stores cluster credentials. Teams that already have strong cluster-level RBAC and a single identity provider may find the extra layer redundant. Teams whose clusters are operated by people who are not cluster admins are the ones who benefit.

The AI assistant is bounded by the user's own permissions

Kite's AI feature is described in two sentences: it can inspect resources, logs and Prometheus metrics, and it reviews and confirms write operations before execution while respecting the current user's RBAC permissions. That second clause is the design decision worth noting. An assistant that inherits the caller's permissions cannot be used to escalate: a user who cannot delete a deployment cannot ask the assistant to delete it. It also means the assistant's usefulness scales with the account you are signed in with, which is a sensible boundary and an unusual one to state explicitly. What the material does not cover is which model provider is used, whether prompts and resource contents leave your network, or how the assistant is configured. The documentation links an AI assistant guide, and that is where those answers would have to come from. Until you have read it, the honest position is that the AI feature is a reason to evaluate Kite, not a reason to deploy it.

Maintenance cost, release cadence and licence

The release history shows a steady cadence: v0.15.1 in September 2026, v0.15.0 the month before, v0.14.1 the month before that. Monthly minor or patch releases on a project still below 1.0 means you should expect to upgrade the chart regularly rather than treat the install as a one-off. The practical cost is that your database schema and chart values move with those releases, so an external database and a values file you keep in version control are what make upgrades routine instead of an incident. The project is Apache-2.0, which permits commercial use, modification and redistribution, and includes a patent grant. It also means there is no copyleft obligation to publish your modifications, and no warranty. Two things follow that are worth stating plainly rather than as legal advice: the licence does not restrict how you host or resell Kite, and the project is funded through donations listed in the README, so there is no commercial support contract behind the release cadence. If you need an SLA, that is a gap you would fill yourself or through a vendor, not something the repository provides.

Editorial conclusion

Adopt Kite if you run several clusters and want one place for resource editing, Helm releases, Prometheus panels and login governance without assembling four separate tools. Do not adopt it if you cannot grant it cluster-wide read and write permissions, or if you need a read-only view of production today. Before rollout, verify three things: that the chart points at an external database or persistent volume, that the default encryption key has been replaced, and that the chart's cluster-wide RBAC rules and the install manifest's cluster-admin binding have been narrowed to what your teams actually need.

Official sources

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