SSA conflict - cub server-side apply vs Helm's silent overwrite on a manual edit

A repository document, rendered for the site. View source markdown.

Generated at: 2026-07-30T12:38:02.000Z UTC · source: committed helm-expt evidence for this rendered repository document.

UNOFFICIAL/EXPERIMENTAL. Live receipt generated by scripts/run-ssa-conflict-gap.mjs; do not hand-edit. Regenerate with npm run ssa-conflict:proof.

Claim. cub's managed delivery uses server-side apply. When a user has manually edited a field (kubectl scale), a server-side re-apply FAILS with a field-manager conflict (a wall of Kubernetes SSA text); Helm's client-side apply silently OVERWRITES and 'just works'. cub's behavior is arguably safer (no silent clobber) but is different and confusing for a Helm user - and under 'people avoid different/confusing' it must be MANAGED with a plain-words message and a clear reconcile/force path, not surfaced raw.

Under the adoption lens (worse-than / more-confusing-than Helm, and managed?): cub's managed delivery uses server-side apply. Proven live on a throwaway kind cluster - a deployment is delivered, a user manually kubectl scales it, then it is re-delivered:

Re-deliveryOutcome on the manually-edited field (.spec.replicas)
cub (server-side apply)yes → CONFLICT (confusing for a Helm user)
Helm (client-side apply)overwrote silently, replicas->1 (Helm's behavior)

Overall: watch. Confirmed: cub's server-side-apply delivery conflicts on a manually-edited field where Helm silently overwrites. Defensible (safer) but different + confusing. Manage it: detect the conflict, explain in plain words ('spec.replicas was changed outside cub - reconcile, or re-apply with --force-conflicts'), and offer the choice - don't surface raw k8s SSA text.