Raw

Some teams want Helm to install a small collection of Kubernetes objects without creating a dedicated chart for each one. The historical raw chart accepted resource definitions in its values and installed them as part of a Helm release. It was a packaging wrapper, not a controller with additional application behavior, and is now deprecated. Moving away from it requires preserving object ownership: uninstalling the old release too early can delete the resources the replacement is meant to retain.

Current guidance

This resource is the incubator/raw Helm chart, not a separate Kubernetes controller. It accepted raw or templated Kubernetes objects in values and added default labels. The chart’s own README marks it deprecated and unsupported. Its examples also contain historical API versions, so replaying them is not a current deployment recipe.

For a small set of owned resources, evaluate a minimal application chart or your existing declarative delivery tool. Choose one owner for each object. A generic resource wrapper can obscure important differences between a namespaced ConfigMap, a cluster-wide PriorityClass and a Secret; they have different access, lifecycle and failure consequences despite sharing one values list.

Before moving resources, record release ownership annotations, namespaces, immutable fields and which objects must survive uninstall. Render and compare the target manifests, then plan the ownership handover without allowing both tools to reconcile or delete the same resource. Keep secret values out of plain-text version control. No current drop-in successor is asserted here, and removing the old Helm release before transferring ownership can delete the very objects being preserved.