Skip to content

Back to the catalog

Gihchathur/kubemotion
github.comrepo

Gihchathur/kubemotion

KubeMotion is a browser-only visualizer that turns raw Kubernetes YAML or a packaged Helm chart (.tgz) into an interactive, Argo CD-style dependency graph without ever connecting to a live cluster or executing Helm. Beyond visualization it runs rule-based checks for common deployment problems — missing probes, incomplete containers, missing selectors, missing service accounts, and mutable image tags — surfaced per-resource in an inspector panel, and can export the resulting architecture as a Mermaid diagram. Built with React, TypeScript, Vite, React Flow and CodeMirror; explicitly a read-only, credential-free tool for reviewing manifests/charts before they're applied.

TL;DR Browser-only, cluster-less Kubernetes/Helm manifest visualizer with light rule-based misconfiguration checks (missing service accounts, mutable image tags, missing probes).
Document

What it is

KubeMotion — a browser-only React/TypeScript app that renders Kubernetes manifests or a packaged Helm chart (.tgz) as an Argo CD-style graph. The catalog summary covers the pitch and the five validation rules; what it omits is the tool's actual scope and the ways its graph diverges from what a cluster would do — the things that decide whether you can trust its output.

How it works (the limits that matter)

Helm charts are not rendered. On .tgz import it reads Chart.yaml, loads the templates/ directory, and applies "safe placeholder processing" to template expressions rather than executing Helm with values. The stated consequence: "Helm templates are inspected in the browser and are not fully rendered with Helm values." So the graph reflects the un-valued template structure, not the manifests that would actually deploy — count on it for shape, not for what a given values.yaml produces.

Relationship detection is rule-based and pattern-limited. It resolves:

  • Ingress → Service
  • Service → Deployment/StatefulSet/DaemonSet/ReplicaSet/Pod
  • Workload → ConfigMap / Secret / PersistentVolumeClaim / ServiceAccount
  • Owner-references where present

It "cannot infer every custom controller behavior," and custom resources render as generic nodes unless they match a known pattern. Recognized kinds are a fixed built-in list (core workloads, RBAC, HPA, PDB, NetworkPolicy, ResourceQuota, LimitRange, ServiceMonitor, etc.) — anything outside it is generic.

Preconditions

Node.js 18+ and npm 9+. It runs locally in-browser; no cluster, credentials, or backend.

npm install
npm run dev

Multi-document YAML separated by --- is supported. Export via Export Mermaid for a flowchart to paste into Markdown/PR/issues.

Caveats

  • No license. The repo states it is "currently intended as a portfolio and educational project. Add a formal license before distributing." As-is it is not open-source-licensed — you have no grant to redistribute or build on it.
  • The graph "describes manifest relationships; it is not a live cluster state view" — it will not show drift, running status, or reconciled objects.
  • Large charts may need namespace/kind/name filtering to stay legible.

Bottom line for the decision: useful as a pre-apply/documentation aid, but treat the Helm output as structural-only and check the license status before any use beyond local review.

Technologies named here

Techniques named here

  • Rule-based validation for common deployment problems
  • Relationship visualization/detection
  • Safe placeholder processing of Helm template expressions