← Back to Helm Values Schema Check
A careful reader genuinely catches the obvious case: a top-level field with a type that's clearly wrong, a required field that's visibly missing on a short file. This page names no company or product — reading values.yaml next to values.schema.json before a release is a habit most chart authors already have, not a competing tool.
The mismatches that sit in plain sight on a short chart are the ones a reader who knows the schema already catches well: replicaCount: "three" where the schema says integer, or a whole required block left out entirely. This tool's type-mismatch and missing-required checks flag exactly the same fields, for the same reason.
| Case | Reading by eye | This tool |
|---|---|---|
A typo'd nested key, e.g. image.repositry | Depends on holding the schema's full property tree in mind while scanning every line of values.yaml — a field that's merely unused looks identical to one that's misspelled | Walks every declared path in the schema against every field values.yaml actually sets, at any depth, every time |
An enum value that's close but wrong, e.g. pullPolicy: IfNotPresnt | Reads as plausible unless the reader happens to recall the schema's exact allowed list for that field | enum-violation checks the literal value against the schema's declared list |
A number outside its minimum/maximum, e.g. replicaCount: 0 against minimum: 1 | Looks like an ordinary integer unless the reader checked that field's bound a moment before | below-minimum/above-maximum compare every numeric field against its declared bound |
| Several unrelated mismatches scattered through a long file | Each individually findable; keeping a running tally of all of them while reading top to bottom is where a manual pass degrades | Reports every finding in one pass, in the same order, regardless of file length |
Whether a nested field is declared, whether an enum value is one of the allowed strings, and whether a
number sits inside its bound are none of them visible on the line itself — each depends on a separate
part of the schema the reader has to keep in mind while scanning a completely different part of
values.yaml. That cross-referencing is the part that degrades fastest as a chart's schema
grows more nested objects and lists. This tool walks the same schema tree against the same values on
every run, regardless of how deep or how long either file is.
This is a schema check, not a chart renderer — it has no connection to Helm's templates, so a
values.yaml that matches its schema perfectly can still produce a broken manifest, and this
tool would not know. It also evaluates only the JSON Schema subset listed on the checker
itself — $ref, oneOf/anyOf/allOf, and regex
patterns are read but not enforced. Deciding whether a flagged field actually matters for your
deployment, and checking schema rules this tool doesn't evaluate, is still a job for reading the files
yourself.
A reader who knows the chart catches the obvious case reliably: a top-level field with a type that's clearly wrong, or a required field that's visibly absent on a short file. Those are real mismatches and a careful side-by-side read finds them the same way this tool's type-mismatch and missing-required checks do.
Whether image.repositry is a typo of image.repository depends on knowing every key the schema declares under image, at whatever nesting depth it sits — not a property visible on the line itself. On a chart with a shallow schema this is manageable; on one with several nested objects the reader has to hold the schema's whole property tree in mind while scanning every line of values.yaml, and a field that is merely unused rather than misspelled looks identical to one that is.
The schema states the allowed enum values or numeric bounds once, often far from any given use of the field, so catching a violation means remembering that list or range while reading a completely different part of the file. A pullPolicy of IfNotPresnt reads as plausible unless the reader happens to recall the exact three strings Kubernetes accepts; a replicaCount of 0 against a minimum of 1 looks like an ordinary integer unless the reader checked the schema's minimum for that exact field a moment before.
Yes, and not in proportion to its length — a reviewer has to hold the schema's structure in mind for every field, and the chance of missing one violation among dozens of nested keys rises with each additional field, not staying flat the way a short, hand-checkable file does. This tool checks every field against the schema the same way regardless of how many there are.
No. This is a schema check, not a chart renderer — it has no connection to Helm's templates, so it cannot tell you whether a value that matches the schema will actually produce a working manifest. Deciding whether a flagged field matters for your deployment, and reading schema features this tool doesn't evaluate ($ref, oneOf/anyOf/allOf, regex patterns), is still a job for reading the files yourself.