📐 Generating values.schema.json for Helm Charts With AI

The first time a teammate set replicaCount: "3" as a string in our production values file, Helm happily rendered it, the Deployment got a quoted replica count, and the API server rejected the object halfway through the release. We caught it, but only after the rollout had already torn down two healthy pods. The fix that stopped this whole class of problem was a values.schema.json next to my values.yaml — and I drafted the first version of it in about ten minutes by handing the schema work to an AI model and reviewing what came back.

This is exactly the kind of task AI is good at: tedious, structural, and easy to verify. Think of the model as a fast junior engineer who can read your entire values file and produce a first-pass schema while you focus on the parts that actually matter for your cluster.

Why a values schema is worth the effort

Helm has supported JSON Schema validation since v3. If a file named values.schema.json sits in your chart root, Helm validates the merged values against it during helm install, helm upgrade, helm lint, and helm template. Validation failures stop the release before anything touches the cluster.

Without a schema, a typo like resource instead of resources, or a port set to "8080" instead of 8080, sails through templating and only blows up when the API server or the running container chokes on it. With a schema, you get a clear error:

Error: values don't meet the specifications of the schema(s) in the following chart(s):
mychart:
- replicaCount: Invalid type. Expected: integer, given: string

That message at install time is worth a hundred postmortems.

Feed the model your values file, not your cluster

Here is the boundary I never cross: the AI sees my values.yaml. It never sees my kubeconfig, my cluster, or any real secret values. A values file is just structured config, and most of it is safe to share. I do scrub anything sensitive first — registry credentials, license keys, internal hostnames — before pasting.

A prompt that works well:

Here is my Helm values.yaml. Generate a values.schema.json (JSON Schema draft-07) that validates types, marks image.repository and image.tag as required, constrains replicaCount to a positive integer, and restricts service.type to an enum of ClusterIP, NodePort, LoadBalancer. Add additionalProperties: false only at the top level.

If you keep your prompts in one place, a saved version of this lives in my prompt workspace so the whole team generates schemas the same way.

What a generated schema looks like

For a typical web-app values file, the model produced something close to this:

{
  "$schema": "https://json-schema.org/draft-07/schema#",
  "type": "object",
  "required": ["image"],
  "properties": {
    "replicaCount": {
      "type": "integer",
      "minimum": 1
    },
    "image": {
      "type": "object",
      "required": ["repository", "tag"],
      "properties": {
        "repository": { "type": "string" },
        "tag": { "type": "string" },
        "pullPolicy": {
          "type": "string",
          "enum": ["Always", "IfNotPresent", "Never"]
        }
      }
    },
    "service": {
      "type": "object",
      "properties": {
        "type": {
          "type": "string",
          "enum": ["ClusterIP", "NodePort", "LoadBalancer"]
        },
        "port": { "type": "integer", "minimum": 1, "maximum": 65535 }
      }
    }
  }
}

The structure was right. But I never trust a generated schema blind — I read every constraint and ran it against real values.

Verify against your actual values

The cheapest verification is to run Helm against the values you already use. Render the chart with your production-like values:

helm lint ./mychart
helm template ./mychart -f values-prod.yaml > /dev/null

If the schema is too strict, this fails loudly with valid input — which is the failure mode you want during review, not during a release. I deliberately test both directions: known-good values must pass, and a few deliberately broken ones must fail.

# Should FAIL: replicaCount as a string
helm template ./mychart --set replicaCount="3"

Pro Tip: AI models love to add additionalProperties: false to every nested object. That feels safe until a subchart or a future feature adds a key and every release breaks. Keep additionalProperties: false at the top level if you want, but be deliberate about it deeper in the tree.

Catch the over-constraint traps

A few patterns I see AI-generated schemas get wrong, every time, and why a human has to review:

• Empty strings. The model marks image.tag as a non-empty string, but your CI might pass an empty tag to mean “use Chart.appVersion.” Decide which behavior you want.
• Booleans rendered as strings. Helm --set enabled=true parses to a boolean, but --set-string does not. Your schema should match how your pipeline actually sets values.
• Resource quantities. cpu: 500m and memory: 256Mi are strings to JSON Schema, not numbers. A naive schema that types them as numbers will reject every valid resource block.

I ask the model a focused follow-up: “Which of these properties are Kubernetes quantity strings rather than numbers?” It usually catches them — but I confirm against the real manifests.

Wire it into CI

Once the schema holds up locally, the schema check belongs in your pipeline so a bad values change fails the build, not the cluster:

- name: Validate Helm values
  run: |
    helm lint ./mychart
    for env in dev staging prod; do
      helm template ./mychart -f "values-${env}.yaml" > /dev/null
    done

If you run an automated review step on chart changes, our code review dashboard flags schema drift — a new value added to values.yaml without a matching schema entry — before a human even opens the PR.

Keep the human in the loop

The schema is config, so generating it is low-risk. But the moment the conversation shifts to “let me run helm upgrade for you,” the answer is no. The model drafts and explains; a human applies anything that mutates the cluster. AI never gets prod credentials, and it never holds a kubeconfig that can reach a real environment.

Used that way, values.schema.json is a near-free win: a structural guardrail drafted in minutes, reviewed by you, and enforced by Helm on every release.

For more on shipping charts safely, browse the Kubernetes & Helm guides, grab ready-made prompts from the prompts library, or pick up the Kubernetes prompt pack to standardize this across your team.