Grafana Helm v4 released

Grafana has released version 4 of its Kubernetes Monitoring Helm chart, changing how teams configure where cluster data gets sent and how collectors are managed. (grafana.com) A Helm chart is a packaged set of Kubernetes deployment files, and Grafana’s chart installs monitoring components such as Node Exporter and the Grafana Alloy Operator to collect metrics, logs, traces, and profiles from a cluster. (grafana.com) Grafana said the chart’s 4.0 update followed nearly six months of planning and development and was published in a blog post on April 13, 2026. GitHub shows version 4.0.0 was tagged about two weeks earlier, and version 4.0.1 followed within days. (grafana.com) (github.com) The biggest change is in “destinations,” the endpoints that receive telemetry data, such as Prometheus for metrics, Loki for logs, OpenTelemetry Protocol for metrics, logs, and traces, and Pyroscope for profiles. In version 3, those destinations were stored as a list; in version 4, they are stored as a map keyed by name. (grafana.com) (github.com) That change targets a common Helm problem: lists do not merge cleanly when teams split settings across shared and per-cluster files. Grafana said version 3 often forced operators using Argo CD, Terraform, or Flux to redefine an entire list just to change one password or cluster-specific field. (grafana.com) Grafana said maps fix that by letting Helm merge configuration files by key instead of by list position. In practice, a team can keep one shared destination named “prometheus” and override only the credential or cluster name in a second file without replacing the rest of the setup. (grafana.com) Version 4 also expands control over “collectors,” which are the Alloy instances that actually gather data inside a cluster. Grafana’s documentation says the chart creates Alloy objects dynamically from configuration choices, and the version 4 release describes collectors as fully customizable. (grafana.com 1) (grafana.com 2) The chart sits in Grafana’s broader push to make Kubernetes monitoring work across different back ends instead of only one stack. Grafana’s documentation says the chart is designed to work with existing systems including OpenTelemetry and Prometheus operators, and its destination docs show support for multiple named outputs in the same deployment. (grafana.com) (github.com) The release also lands as Grafana continues to ship changes around Kubernetes Monitoring in 2026, including a redesigned configuration flow in version 2.28.0 of the product’s user interface on March 11 and setup fixes in version 2.28.1 on March 16. (grafana.com) For operators running one cluster, version 4 reduces some YAML editing. For teams running dozens or hundreds, Grafana is pitching it as a safer way to reuse one monitoring chart across many clusters without breaking routing when a list gets reordered. (grafana.com)