Helm management

Radar reads the Helm release secrets directly from K8s (no helm binary needed), so every release shows up automatically. From there you can see what’s running, understand failed deployments, compare revisions, upgrade, rollback, or uninstall.

​

What you see

The Helm view lists every release, scoped to namespace or cluster-wide:

• Release name, namespace, chart, chart version, app version.
• Status (deployed, pending, failed).
• Revision number and last deploy time.
• Owning resources (Deployments / StatefulSets / etc. that the release manages).
• Operation signals for failed installs or upgrades, stuck pending operations, and rollback-after-failure sequences.
• Source and ownership signals, including Flux-managed releases and releases whose upgrade source cannot be resolved.

Click a release for the detail view:

• Overview - chart metadata, release description, source state, current operation insight, and the best live resource to inspect when Helm recorded a rollout failure.
• Resources - every K8s resource in this release, linked to its row in the resource browser.
• Values - the user-supplied values, side by side with the chart defaults.
• Manifest - the fully rendered manifest as Helm produced it.
• Notes - the chart’s NOTES.txt.
• History - all revisions with timestamps, descriptions, and a per-revision diff.

​

Compare revisions

Each revision shows a structured diff against the previous one, and you can pick any two revisions to compare across values, rendered manifest, notes, hooks, and resources - not just adjacent ones. Compare opens a full-page workspace so the rendered output has enough room to be useful:

• Manifest diff - line-by-line YAML diff of the rendered manifests. This is the source of truth when the chart changed names, labels, templates, or object identity.
• Rendered resource inventory - a compact index of which Kubernetes objects were added, removed, or changed in place. When object identities do not overlap, Radar says so and points you back to the manifest diff instead of pretending it can pair unrelated objects.
• Field-level resource changes - for objects that can be paired by kind, namespace, and name, Radar highlights meaningful spec changes such as image, probes, replicas, selectors, and ports.
• Values diff - which user-supplied values changed.
• Notes diff - changes to the chart’s NOTES.txt.
• Hook evidence - hook metadata and any retained Job / Pod / Event / log evidence associated with failed or running hooks.

​

Upgrades, rollbacks, uninstalls

Read-only mode: pass --disable-helm-write (or run without rbac.helm) and the action buttons disappear; you still see everything.

​

Diagnosing failed upgrades and hooks

When an upgrade goes wrong, Radar reconstructs what happened from release history instead of leaving you to read raw revision rows:

• Failed upgrades and atomic rollback. Helm doesn’t persist whether --atomic was set, so Radar infers an atomic-style rollback from the revision sequence - a failed upgrade revision followed by a deployed rollback that points back to the previous release - and surfaces it as one operation (failed revision, rollback revision, target revision, and the failure description Helm recorded) rather than an ordinary healthy rollout.
• Stuck pending operations. Pending installs, upgrades, and rollbacks get called out as active Helm operations, not just generic Kubernetes readiness problems.
• Likely resource to inspect. When Helm’s failure description names a live Kubernetes object, Radar links that object and shows its readiness/status signal so you can move from release history to the resource that blocked the rollout.
• Hook forensics. For a failed or running hook, Radar shows the hook’s identity, path, weight, lifecycle events, and last-run phase, and correlates the live Job / Pod / Event evidence plus short, secret-redacted log snippets when your identity can read them.
• Best-effort evidence. Hook delete policies, ttlSecondsAfterFinished, garbage collection, or RBAC can remove the Job / Pod / Event / log data after Helm records the phase. Radar says when evidence is unavailable instead of pretending the hook didn’t fail.

Native Helm install / upgrade failures also surface in Issues and reach AI agents over MCP.

​

Version-aware upgrades

When a newer chart version is available, the release shows an update badge. The upgrade dialog lets you pick a specific target version - not just the latest - from the newest 50 versions (type to filter). Selecting a version older than what’s installed is labelled as a downgrade. Upgrades run with Helm’s --reset-then-reuse-values, so your previously-supplied values are preserved while the new chart’s new default keys are picked up (plain --reuse-values can render nil for keys a newer chart added).

​

Chart sources and upgrades

Upgrades require a confirmed chart source: its repository URL and chart name, or full OCI path. Open Choose chart source, select a configured source and use Check and record source. A name match or update badge does not verify where the installed chart came from; older source records may need confirmation. For public charts, choose ArtifactHub → Search ArtifactHub. This sends only the installed chart name, after your click. Review the publisher and address, then add the repository or OCI prefix. Use Add manually for private sources. Adding a source saves configuration without changing the release. Sources are shared; only owners can add or remove them in Radar Cloud. Configure repositories where Radar runs; your laptop’s Helm cache may differ. For OCI charts, register a prefix such as oci://ghcr.io/myorg/charts. Private OCI sources need credentials from helm registry login available to Radar, including when it runs in-cluster. Review the version, settings and rendered changes before upgrading. Changing the source or settings requires a fresh preview. Values-only edits can use the stored chart unless dependencies are missing. Previews cannot guarantee hook, data or immutable-field compatibility; Helm does not upgrade CRDs from crds/.

​

GitOps-managed releases

If a release was installed by Flux’s helm-controller, a direct helm upgrade would be reverted at the next reconcile. Radar detects this, shows a Managed by Flux chip, and routes you to the GitOps view to bump the version in Git - rather than offering an in-place upgrade that wouldn’t stick.

​

AI and MCP

Radar exposes the same Helm context to AI agents through MCP:

• list_helm_releases returns release status, resource health, Flux ownership, current operation insight, and a capped operation trail.
• get_helm_release returns detailed release data, owned resources, history, operations, hooks, and hook diagnostics. Include diff options to compare revisions.
• issues includes active native Helm failures and stuck pending operations as kind=HelmRelease, group=helm.sh.
• get_changes includes native Helm release deployment history with source: helm, so agents can answer “what changed before this broke?” without scraping the UI.

​

Concurrent edits

If two operators try to upgrade the same release at the same time, Helm’s own lock (the release pending-upgrade state) wins - Radar surfaces the conflict instead of silently overwriting. Failed upgrades show the failure reason and offer a one-click rollback.

​

See also

• Resource browser - every Helm-managed resource shows its release.
• GitOps (Flux & Argo) - if you’d rather manage Helm declaratively.
• In-cluster deployment - rbac.helm opt-in.