A minimal Chart.yaml
The fields Helm requires, and the ones it silently accepts as missing
apiVersion: v1 name: web version: 1.0.0
Check a chart's metadata, its values and its values.schema.json against each other. It does not render templates, which is what helm template is for and what no linter can do.
Optional, and the most useful thing a chart can add: a schema is enforced on every install, so it catches a bad override before anything renders.
Or drop a file anywhere on this panel. Nothing is uploaded: the analysis runs in this tab.
The answer appears here
Paste on the left and press Check. Nothing leaves this tab.
Nothing else to flag.
No formatting problems, and nothing the rules object to. Worth remembering what that covers: this reads the file you pasted, not the account or cluster it will be applied to.
No finding matches that filter.
Real input you can load into the tool above. Each one shows a different thing going wrong, because that is what the tool is for.
The fields Helm requires, and the ones it silently accepts as missing
apiVersion: v1 name: web version: 1.0.0
Dependencies moved into Chart.yaml in v2, which changes what requirements.yaml means
apiVersion: v2
name: web
version: 1.0.0
type: application
dependencies:
- name: redis
version: 17.x.x
repository: https://charts.bitnami.com/bitnamiThese are the ones that fail silently. The config is accepted, nothing raises an error, and the consequence arrives later.
Dependencies live in requirements.yaml for v1 and in Chart.yaml for v2. A v2 chart with requirements.yaml silently ignores it.
Instead:Set apiVersion: v2 and put dependencies in Chart.yaml.
Helm requires semver for version. A value like 1.0 is rejected on package.
Instead:Use three components.
version is the chart's, appVersion is the application's. Bumping only appVersion means the chart never changes for Helm.
Instead:Bump version on every chart change.
They are different fields with different rules. Helm refuses a chart whose `version` is not SemVer 2 exactly, and accepts almost anything in `appVersion`, which is why the two look interchangeable and are not.
`appVersion: 1.10` parses as a number, so it becomes 1.1, and `1.0` becomes 1. The value that reaches your templates is not the one written in the file, and nothing warns. `helm create` quotes it by default for exactly this reason.
A bare `kubeVersion: 1.29` means exactly 1.29 and nothing else, so the chart refuses to install on 1.29.4. Write a range. The `-0` in `>=1.29.0-0` matters too: SemVer sorts a pre-release below its release, so without it the constraint rejects pre-release and some managed-distribution builds.
The templates. Whether the chart produces valid Kubernetes objects is a different question and only `helm template` answers it, because rendering needs the whole chart directory. The Go template tester on this site renders a single template against values, which covers the common case of one file being wrong.