Helm

version is the chart package's own version and must be valid SemVer 2; Helm names the tarball, indexes and resolves the chart from it. appVersion is a free-form label naming the application release the chart ships, and Helm never parses it.

Files under crds/ are plain YAML that Helm never renders as templates. Helm applies them before anything in templates/, skips any CustomResourceDefinition already present in the cluster, and never updates or deletes them.

helm package compresses a chart directory into a gzipped tar named <name>-<version>.tgz, with both parts read from Chart.yaml. The version must be valid SemVer 2, and the archive unpacks into one directory named for the chart.

Helm evaluates every file under templates/, but output from a file whose name begins with an underscore or a dot never becomes a manifest. NOTES.txt becomes the release notes, and a file rendering to only whitespace is dropped.

helm show values prints a chart's values.yaml exactly as the author wrote it, comments included, without installing or rendering anything. That file is the chart's default surface: every key a consumer may override, and the value they get if they do not.

Helm binds .Values, .Release, .Chart, .Files, .Capabilities, .Template and, in a parent chart, .Subcharts. .Values holds the merged user values, .Release describes this install, and .Chart mirrors Chart.yaml with capitalized field names.

helm template never contacts an API server, so Helm's lookup has nothing to query and returns an empty map rather than failing. Only a render that reaches a cluster — a real install, an upgrade, or --dry-run=server — fills it in.

helm template <release-name> <chart> renders the chart with the values you pass and prints the resulting YAML to stdout — no cluster call, no release record. Adding -s/--show-only templates/job.yaml limits the output to that one template file's manifests.

Helm's default function substitutes a fallback when a values entry is empty, so the render continues. required does the opposite: it aborts the whole render with the message you wrote. Use default for optional settings, required where no safe fallback exists.

include is a function Helm adds: it renders a named template and returns the output as a string, so it can be piped into other functions. template is a Go template action that writes straight to the output and yields no value.

The Kubernetes API server rejected the write because the chart's new manifest changes a field that cannot change after the object was created — a Deployment's spec.selector is the classic one. Helm records the attempt as a failed revision and the live object keeps its old spec.

helm upgrade --install upgrades a release when one with that name already exists in the namespace and installs it when none does. Pipelines use it because the same command works on the first deploy and every deploy after it.

Helm sorts every rendered manifest by Kubernetes kind using a fixed, hard-coded list: Namespace first, then config and RBAC, then Service, then workloads, then Ingress. File names under templates/ do not decide the order.

An object of that kind and name is already in the cluster and does not carry this release's Helm ownership metadata. Helm refuses to overwrite anything it cannot prove belongs to the release being applied.

Helm writes one Secret per release revision into the release's own namespace, named sh.helm.release.v1.<name>.v<rev> with type helm.sh/release.v1. It carries the chart, the values supplied, the rendered manifest and the status, as JSON that is gzipped and base64-encoded.

condition names a dotted values path, such as database.enabled, on a Chart.yaml dependency entry. If that path resolves to a boolean, it decides whether Helm renders that subchart at all. If the path is absent, the condition is ignored and the dependency stays enabled.

Each dependencies entry declares one subchart the chart bundles: name is the chart to fetch, version is a SemVer range the fetched chart must satisfy, and repository says where to fetch it from. Optional fields such as alias refine that.

An oci:// reference is a registry path whose last segment is the chart name and whose tag is the chart version. Commands take the whole path; a Chart.yaml dependency puts the path without the chart name in repository, and the chart name in name.

Collect the packaged .tgz files in one directory, run helm repo index on that directory to generate index.yaml, and serve the directory over HTTP. A chart repository is static files - no chart-server software is required.

helm repo add saves a name-to-URL entry in your local repositories.yaml and downloads that repository's index.yaml into a cache directory. Helm resolves chart names from that cached copy and never refreshes it on its own, so a version published after your last helm repo update is invisible.

helm test looks up an installed release, creates the manifests in it that carry the helm.sh/hook: test annotation - usually Pods - waits for them to finish in the release namespace, and reports pass or fail through its exit code.

It turns that manifest into a lifecycle hook. Helm keeps it out of the release manifest and applies it on its own at the named point, such as pre-install or post-upgrade, waiting for it to succeed before the operation continues.

Ship the migration as a Kubernetes Job template inside the chart, annotated with helm.sh/hook set to pre-install,pre-upgrade. Helm applies that Job and waits for it to complete before applying the chart's own manifests, so the schema changes before any new pod starts.

before-hook-creation deletes an object of the same kind and name just before the hook is created; hook-succeeded deletes it once the hook succeeds; hook-failed deletes it when the hook fails. With the annotation absent, Helm applies before-hook-creation.

Only pre-upgrade and post-upgrade fire on helm upgrade. The install, delete, rollback and test events belong to their own commands, so a hook that must run on both the first deploy and every later one has to list two events.

Helm renders a chart's Go templates against values, so the final YAML is generated from files that are not YAML. Kustomize patches complete YAML instead. Helm also stores each apply as a release; kubectl apply -k stores nothing.

helm upgrade runs once: it renders the chart, sends the result to the API server, records a new release revision and exits. Nothing then watches the cluster, so drift survives until somebody runs Helm again.

Each helm install or upgrade stores the rendered manifest, its values and a status as a release revision in a namespace Secret, so helm rollback can re-apply an earlier one. kubectl apply -k stores nothing; undoing it means rebuilding the older source.

You lose the release record: the stored manifest and values per revision, helm history and helm rollback, membership tracking that prunes removed resources and cleans up on uninstall, hook ordering, helm test, and the wait behaviour Helm applies after writing.

When there is one deployment target and nothing genuinely varies between deployments. A chart then adds Chart.yaml, templates/ and a values indirection to produce the YAML you already wrote, and reviewers must render it to see what ships.

Helm keeps no target state of its own. It acts on the kubeconfig's current context unless --kube-context overrides it, and targets the namespace from -n, else HELM_NAMESPACE, else the namespace recorded on that context, else default.

Nothing has to be done to them. Helm 4 adopts Helm 3 releases in place: the release record is still a Secret in the same format and v2 charts still install, so there is no migration tool and nothing to convert.

helm list shows releases in one namespace - the current kube context's, or the one -n names; -A lists every namespace. Helm 4 lists all statuses by default, so flags like --failed narrow the list rather than widening it.

Because Helm must decode the previous release's stored manifest on every upgrade, and that text is frozen at install time. Fixing the chart changes what you render, not the retired apiVersion already recorded with the live release.

Helm stores the manifest it applied in the release record and never watches the cluster afterwards. helm status reads that record, so it reports the outcome of the last operation, not whether the live objects still match it.

The caller's own kubeconfig identity. Helm 3 and 4 ship no in-cluster server component: the CLI renders the chart locally, then writes every rendered object — and the release record — as whoever ran the command.

Nothing confidential. b64enc is base64 encoding, needed only because a Kubernetes Secret's data field must hold base64 text. It is reversible by anyone, and the same plaintext still sits in the values file and in the stored release record.

A values entry is caller input pasted into YAML before anything parses it. Unquoted, its characters are read as YAML syntax: 1.10 becomes 1.1, off becomes a boolean, a newline can add fields. quote forces one string scalar.

Render it before you trust it: helm template, run with the values you will actually install with, prints every manifest the chart applies and touches no cluster. Add --include-crds — the chart's crds/ directory is excluded by default.

No. Helm checks a chart's OpenPGP signature only when you pass --verify, and only if the publisher signed the chart with helm package --sign so a .prov file exists, and the public key sits in the keyring you point --keyring at.

helm lint loads the chart, renders it and reports structural problems as an exit code, so it works as a pass/fail gate. helm template prints the manifests the chart produces, so a reviewer can diff the YAML the change actually generates.

helm template only renders a chart to YAML on stdout; helm install renders it, applies it, and records the release in the namespace. Objects applied from rendered YAML have no release record, so helm list, helm history and helm rollback see nothing.

Helm pipes its rendered manifest stream into another program's stdin and uses the YAML that program returns on stdout. That returned YAML becomes the release's manifest, so you can patch a chart you do not own without forking it.

Keep one chart whose values.yaml holds the defaults true everywhere, then pass a small per-environment file at deploy time: helm upgrade -f values/prod.yaml. Only keys that genuinely differ live in that file; the chart is identical everywhere.

helm install fails when the release name already exists and helm upgrade fails when it does not, so neither is safe to re-run. helm upgrade --install picks whichever applies, letting one deploy job serve a first deploy and every later one.

helm lint parses the chart metadata, renders the templates with the values it is given, and reports INFO, WARNING and ERROR findings. It never contacts a cluster, so a manifest that renders as valid YAML but is an invalid Kubernetes object still passes.

Defaults that render runnable YAML with no -f file: every key a template reads is present and typed, empty extension points declared as {} or [], nothing secret or site-specific baked in, and required inputs failing the render loudly.

An umbrella install is one release, so an upgrade is one operation with one outcome: work already applied stays live, the release is marked failed, and an automatic rollback reverts every service, not just the broken one.

Because a Deployment's spec.selector cannot be changed after creation. Charts emit version-bearing labels such as helm.sh/chart and app.kubernetes.io/version that change on every version bump, so the selector must hold only stable labels - normally name and instance.

The chart hashes its rendered ConfigMap template and writes the hash into the Pod template's annotations. When the config changes the hash changes, the Pod template changes, and the workload controller performs a normal rolling update. Helm itself never reads the annotation.