kฮ
kdelta answers four questions about your Kubernetes cluster: what's deployed, what version is it, what changed upstream since then, and what happens to the rest of the system if you upgrade it.
How it works
A four-stage pipeline; each stage caches its output for the next. Everything before impact is deterministic or provenance-labeled.
Detectors read the cluster โ Helm release storage today, more on the roadmap โ and upstream identity is resolved from public indexes, verified against the deployed chart's own metadata.
Deterministic, no AI: versions are enumerated from the upstream source verified at scan time and ordered against the deployed version under the stream's scheme.
Release notes are fetched verbatim, then structured by a model into a normalized change set โ every entry labeled with its provenance and streamed as it extracts.
An agent cross-references the change set against live cluster state through a confined, read-only tool surface, and reports findings, actions, and honest gaps.
Getting started
Run the container image โ CLI, API, and web UI in one โ then open http://localhost:8080. Drop the -v/-e flags for a UI-only tour without cluster or AI access.
docker run --rm -p 8080:8080 \ -v ~/.kube:/home/nonroot/.kube:ro \ -e CLAUDE_CODE_OAUTH_TOKEN \ ghcr.io/shadiramadan/kdelta:latest serve --bind :8080
The CLI runs the same pipeline against your current kubeconfig context. scan and versions need only cluster and network access; impact needs a Claude credential (a subscription via the claude CLI, or an API key), which changes uses too โ without one it serves the release notes verbatim.
kdelta scan # detect deployed resources + versions + upstream links kdelta resources # list detected resources from the cached scan kdelta versions <resource> # versions since the deployed one (no AI) kdelta changes <resource> # changelog for the version range kdelta impact <resource> # AI-assessed blast radius of the upgrade kdelta serve # ConnectRPC API + embedded web UI
Installing from source? go install github.com/shadiramadan/kdelta@latest builds the CLI and API (the web UI is embedded by container builds and task install from a clone). See CONTRIBUTING.md for the dev environment.
What's underneath
The CLI, the ConnectRPC API server, and the embedded web UI ship together. Commands run against an in-process server by default, or a remote one with --server โ same code path either way.
Every contract lives in proto/ with protovalidate rules; the Go server and the TypeScript UI consume generated clients from the same source of truth.
Observed from the cluster, fetched verbatim, or AI-extracted โ how each fact was produced is a schema field, not a footnote, so results can be audited.
Release notes are third-party input. The impact agent runs with built-in tools disabled and reaches the cluster only through a no-secrets allowlisted view โ Secrets are never listable and env values are redacted.
Each stage reuses the previous stage's cached output. Change sets are cluster-independent, so an assessment never re-scans, re-resolves, or re-extracts what is already known.
Container images on GHCR are cosign-signed with SBOMs and build-provenance attestations, published by CI from tagged releases.
The full picture โ trust boundaries, the detector seam, cache invalidation โ lives in ARCHITECTURE.md; what's deliberately not built yet lives in ROADMAP.md.