A minimal Chart.yaml
The fields Helm requires, and the ones it silently accepts as missing
apiVersion: v1 name: web version: 1.0.0
Kubernetes Helm Chart Validator
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.
Paste below, or drop a file anywhere on this panel
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.
Formatted
Results
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.
Examples
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.
An apiVersion v2 chart
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/bitnamiCommon mistakes
These are the ones that fail silently. The config is accepted, nothing raises an error, and the consequence arrives later.
Mixing apiVersion v1 and v2 conventions
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.
Using a version that is not semver
Helm requires semver for version. A value like 1.0 is rejected on package.
Instead:Use three components.
Confusing version and appVersion
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.
version must be SemVer 2 and appVersion need not be
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 needs quoting or YAML changes it
`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.
kubeVersion is a constraint, not a version
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.
What this cannot see
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.
Related kubernetes tools
Kubernetes Helm Values Diff A missing key is a third value Kubernetes Helm Chart Generator Chart.yaml, values, and working templates Kubernetes Go Template Tester Go truthiness is not JavaScript's Kubernetes YAML Validator Is this YAML valid, and where is it wrong? Kubernetes Resource Name Validator RFC 1123 subdomain, label, or 1035 Kubernetes Label & Annotation Validator Why your image tag is not a legal label
All 55 kubernetes tools