Yes. The optional kubeVersion field in Chart.yaml holds a SemVer constraint on supported Kubernetes versions, and Helm checks it at install time, failing if the cluster version is unsupported. It is a cheap guardrail for shared charts, with clear limits.
What Helm documents
Helm's chart documentation describes kubeVersion as an optional SemVer constraint on supported Kubernetes versions. Helm checks it at install time and fails if the cluster version is not supported. Constraints such as >= 1.13.0 < 1.15.0 are supported, and you can combine them with || for OR logic.
Example:
apiVersion: v2
name: platform-service
version: 2.3.0
kubeVersion: ">= 1.27.0"
The constraint above is an illustration. Pick a floor that matches the Kubernetes versions your platform supports, using your own support policy.
Why a shared chart wants it
A shared chart can render objects that older clusters do not understand, or that behave differently. Without a constraint, the failure shows up later, as a confusing API error or a silently ignored field. With one, Helm stops at install with a clear reason.
For security, the more interesting case is a field that older clusters ignore. If a chart sets a security related field that an old API server drops without complaint, the workload runs without the protection you thought you had. A floor on the cluster version prevents that class of surprise. Verify for your own objects whether older versions ignore a field, using Kubernetes documentation for the specific field.
Setting the floor
- List the Kubernetes API versions and fields the chart's templates use.
- Find the earliest Kubernetes release that supports all of them.
- Set
kubeVersionto that floor, or a range if you know an upper bound that is unsupported. - Treat raising the floor as a notable change, with release notes. Consumers on older clusters will fail to install the new chart version.
- Test installs against your oldest supported cluster in CI.
What it does not do
| Question | Answer |
|---|---|
| Does it check the chart is safe? | No, it checks cluster version only |
| Does it stop upgrades of existing releases? | The docs describe the check at install time, so test your upgrade path |
| Does it replace testing on older clusters? | No, it only blocks, it does not prove compatibility |
| Does it detect deprecated APIs in use? | No |
On the second row, test it in your environment rather than assuming either way.
Version bumps for a floor change
Raising kubeVersion changes who can install the chart, so it affects consumers like a breaking change. Many teams bump the major version for it, but that is a policy choice. Decide it once and write it down. See version vs appVersion.
Pair it with review and signing
A guardrail inside a chart is only as trustworthy as the chart. Consumers who care that the chart is the reviewed one can use provenance. See signing and verifying a Helm chart, and note what helm verify does and does not prove.
Where Safeguard fits
Safeguard gates can require review of pull requests that change Chart.yaml, and its evidence automation can record the approvals. The Kubernetes version floor itself is a chart author decision.
Quick check
Is kubeVersion required?
No, it is optional. If you omit it, Helm does not enforce a cluster version.
Can I allow two separate Kubernetes ranges?
Yes. Helm supports combining constraints with the OR operator, written as two vertical bars.
Sources
Last reviewed: 19 October 2026.
