kubeconform vs kubeval (2026): Validate K8s Manifests

If you are choosing a Kubernetes manifest schema validator in 2026, the decision is already made for you: kubeconform vs kubeval is really “the maintained successor vs the deprecated original.” Both answer the same question - does this YAML conform to the Kubernetes API spec for the version you target? - but only one of them is still being maintained.

This page draws the line clearly so you can migrate with confidence. For the broader picture of how schema validation fits alongside security and best-practice scanners, see our kube-score vs kubeaudit vs Checkov vs Trivy comparison.

The short answer

• Pick kubeconform if you are starting fresh, want faster CI, need newer Kubernetes API versions, or have to validate custom resource definitions (CRDs). This is almost everyone.
• Pick kubeval only if you are maintaining a legacy pipeline that already depends on it and you have no time to migrate yet. It still runs, but it is deprecated and unmaintained.
• Both do the same fundamental thing - schema validation against the Kubernetes OpenAPI spec - so migrating between them is low-risk and usually quick.

Deciding factor to pick

The rule: unless you are temporarily stuck on a legacy kubeval setup, use kubeconform.

What each tool is

• kubeval is the original Kubernetes manifest schema validator. It checks whether your YAML conforms to the Kubernetes OpenAPI / JSON schemas - the right fields, the right types, valid for a given API version. It was widely adopted for years, but it is now deprecated and no longer actively maintained, and the project itself points users toward kubeconform.
• kubeconform is the faster, actively maintained drop-in successor to kubeval. It does the same schema validation, but it validates manifests in parallel for speed, tracks newer Kubernetes API versions, and supports CRD validation through custom schema locations. It is built to be CI-friendly and is the tool to reach for today.

kubeconform vs kubeval: head-to-head

The cells that decide it: kubeconform wins on maintenance, speed, newer API support, and CRD validation. kubeval matches it only on the basics, and trails everywhere that matters going forward.

When to choose kubeconform

• You are starting any new validation pipeline in 2026 and want a tool that will still be maintained next year.
• You target recent Kubernetes API versions and need the schemas to keep up.
• You need to validate custom resource definitions for tools like cert-manager, Argo, or Istio via custom schema locations.
• You run validation on every pull request and want the parallel speed to keep CI fast on large manifest sets.
• You want clean machine-readable output (JUnit, JSON) to wire into CI gates.
• You are migrating off kubeval and want a near drop-in replacement.

When to choose kubeval

• You have an existing pipeline that already depends on kubeval and you have not scheduled the migration yet.
• You are only validating against older clusters whose API versions kubeval still covers.
• You need a stopgap while you plan the switch - but treat this as temporary, because the project is deprecated and will only fall further behind.

In every one of these cases, the honest recommendation is still to plan a migration to kubeconform. There is no scenario in 2026 where kubeval is the better long-term choice.

Can you use them together?

There is little reason to run both - they do the same job, and kubeconform supersedes kubeval. The realistic pattern is a migration, not a coexistence: swap the binary, port your flags (kubeconform keeps the spirit of kubeval’s interface), and add -schema-location entries for any CRDs you need. Run kubeconform once in CI and retire kubeval.

Where tools genuinely combine is across layers, not against each other. Schema validation is the first gate; best-practice and security scanning come next. See Polaris vs kube-score for the best-practice layer that runs after schema validation passes.

Cost comparison

There is nothing to compare on price - both kubeconform and kubeval are free and open source, kubeval under Apache 2.0 and kubeconform under Apache 2.0. The real cost is operational. kubeval’s deprecation means you eventually pay in maintenance debt: stale schemas, missing API versions, and no upstream fixes. kubeconform’s active maintenance and parallel validation keep both CI minutes and engineering time down. The cheaper tool over any real time horizon is kubeconform.

Common pitfalls

• Treating schema validation as security validation. kubeconform tells you a manifest is valid, not that it is safe or well-configured. You still need best-practice and security scanners on top.
• Expecting CRDs to validate out of the box. kubeconform supports CRDs, but you have to supply their schemas via custom schema locations - it does not ship them.
• Staying on kubeval “because it still works.” It works until a Kubernetes upgrade introduces API versions kubeval never learned, and then it silently passes or wrongly fails manifests.
• Skipping schema validation entirely and letting kubectl apply be your first check - that pushes errors all the way to the cluster instead of catching them in CI.
• Not pinning the target Kubernetes version. Validate against the API version your cluster actually runs, or you will validate against the wrong schema and trust a green check that means nothing.

Related

• Deployment gates in kubeqa
• Polaris vs kube-score
• kube-score vs kubeaudit vs Checkov vs Trivy
• Kubernetes QA tools comparison

Schema validation is exactly the kind of check that belongs at the front of a deployment gate, and kubeqa validates manifests as part of its gates so a structurally invalid or stale-API manifest never makes it to the cluster. It runs schema validation alongside best-practice and security checks behind a single score, so you get correctness, hardening, and policy in one pass instead of stitching tools together by hand.

Install it and try it on your own manifests:

brew install nomadx-ae/tap/kubeqa

Star kubeqa on GitHub