// the find
carvel-dev/kapp
kapp is a simple deployment tool focused on the concept of "Kubernetes application" — a set of resources with the same label
kapp is a Kubernetes deployment CLI that treats a labeled set of resources as a single 'application' and manages the full create/update/delete lifecycle against a live cluster. It sits between raw kubectl and Helm — no templating, no packaging, just diffing your YAML against cluster state and converging to it. The target user is a platform engineer who already has a way to generate Kubernetes YAML and needs reliable, auditable apply logic.
The diff-then-apply separation is the killer feature: you see exactly what will change before anything touches the cluster, and the diff is against live objects not last-applied annotations. Dependency ordering via annotations (CRDs before everything, custom ordering rules) handles the real-world sequencing problems that kubectl apply silently gets wrong. No server-side components means you can drop it into a CI pipeline or a restricted namespace without cluster-admin buy-in. The CRD upgrade safety preflight checks (pkg/kapp/crdupgradesafety/) are a genuine differentiator — catching breaking schema changes before apply is the kind of thing that saves a 2am incident.
1067 stars is low for a tool that's been around this long and is part of the VMware/Broadcom Carvel suite — adoption signals that it never broke out of that ecosystem bubble. No server-side apply by default; the label-based ownership model can conflict with other tooling managing the same cluster, leading to resources kapp doesn't own showing up in diffs in confusing ways. The rebase rules system (for things like HPA/PVC) is powerful but requires reading a separate doc to understand why your diff looks wrong; it's not self-documenting. The wait logic is polling-based and the convergence timeout behavior is not configurable per-resource-type without writing custom wait rules, which is friction when you have resources with wildly different stabilization times.