Context

Rancher supports deploying applications via Helm charts. Currently, there are multiple installation methods used in the ecosystem:

• Rancher UI (the only team-supported installation path)
• Terraform
• Helm CLI -Automation tools such as Ansible, Argo CD, GitOps pipelines, etc.

The Rancher UI contains proprietary logic that collects cluster metadata, management-plane information, and chart-specific configuration requirements. Then automatically generates a set of mandatory values required for the correct installation and operation of the chart. Injecting these values before calling the Helm installation endpoint. Examples of this logic include capturing the cluster type (RKE2/K3s), version constraints, feature flags, management addressing, ingress settings, cloud provider integration parameters, and more. Terraform-based installations rely on documentation that customers must follow manually, specifying required values. This documentation frequently lags behind version changes. Meanwhile, methods like Helm CLI provide no support at all, forcing users to manually reverse engineer values that are normally injected by the UI. UI logic:

rancher/dashboard/install.vue

rancher/dashboard/resource-fetch

Motivation

Other methods require the user to manually specify mandatory values. This leads to recurring issues in the community (e.g #43406 and #49955), especially during Rancher version upgrades, when required values change but documentation and tooling do not automatically update. Users installing charts through Terraform or other clients fail because they do not know about these additional required values, and Rancher cannot fully support these installations. A centralized controller eliminates these discrepancies. It ensures the Rancher team can support all installation methods, not just the UI.

Goals

• Move all mandatory-value collection and injection logic out of the Rancher UI into a dedicated controller.
• Ensure consistent chart installation behavior across all clients (UI, Terraform, Helm CLI, automation tools).
• Continuously monitor installed charts and reconcile required values whenever templates, charts, or clusters change.
• Enable Rancher engineering/support to confidently support all installation methods because behavior becomes consistent.
• Reduce failures caused by missing or outdated required values during upgrades.

FYI

I also created a RFC for the project, where I'm initially going to maintain/update the project documentation. Everyone can check and make some comments here!