# kubeval Deprecated: Migrating to kubeconform

> kubeval is archived; kubeconform is the maintained replacement. Reference mapping kubeval flags to kubeconform and the migration gotchas in CI.

Source: https://latchkey.dev/learn/command-reference/kubeval-deprecated  
Updated: 2026-06-30

kubeval is no longer maintained; replace it with kubeconform, which tracks current Kubernetes schemas, runs in parallel, and supports CRDs via -schema-location.

If a pipeline still calls kubeval and is failing on recent apiVersions, the fix is usually to migrate to kubeconform rather than to wrestle with kubeval schemas.

## Why migrate

kubeval is archived and ships schemas that trail current Kubernetes, so manifests using newer apiVersions fail with `could not find schema`. kubeconform is actively maintained, faster (it parallelizes), supports CRD schemas through `-schema-location`, and offers junit/tap/json output for CI.

## Flag mapping

| kubeval | kubeconform |
| --- | --- |
| --strict | -strict |
| --kubernetes-version 1.x | -kubernetes-version 1.x |
| --ignore-missing-schemas | -ignore-missing-schemas |
| --skip-kinds A,B | -skip A,B |
| -o json | -output json |

## Migration example

```Terminal
# before
kubeval --strict --kubernetes-version 1.29.0 manifests/
# after
kubeconform -strict -kubernetes-version 1.29.0 -summary manifests/
```

## In CI

kubeconform reads stdin with `-`, so the kustomize pipeline becomes `kustomize build overlay | kubeconform -strict -`. Both tools exit non-zero on failure, so the pipeline gate behaves the same after swapping the binary and renaming flags.

## Common errors in CI

After migrating, `could not find schema for <CRD-Kind>` appears for custom resources kubeval happened to skip; add their schemas with `-schema-location` or `-ignore-missing-schemas`. A double-dash flag like `--strict` passed to kubeconform errors with `flag provided but not defined`; kubeconform uses single-dash flags.

## Using this in CI

A runner has no kubeconfig, no cached context, and no interactive auth. Every kubectl invocation in CI needs the context supplied explicitly, and most confusing CI failures here are the command running against the wrong cluster or no cluster at all.

```Terminal
# never rely on the ambient context on a runner
kubectl --context "$KUBE_CONTEXT" -n "$NAMESPACE" get pods

# confirm what you are actually connected to before mutating anything
kubectl config current-context
kubectl cluster-info

# fail fast instead of hanging on an unreachable API server
kubectl --request-timeout=30s get nodes
```

> Always set `--request-timeout` in CI. Without it an unreachable API server hangs until the job times out, which turns a thirty-second failure into a twenty-minute one.

## FAQ

### kubeval Deprecated: Migrating to kubeconform?

If a pipeline still calls kubeval and is failing on recent apiVersions, the fix is usually to migrate to kubeconform rather than to wrestle with kubeval schemas.

### Why migrate?

kubeval is archived and ships schemas that trail current Kubernetes, so manifests using newer apiVersions fail with could not find schema. kubeconform is actively maintained, faster (it parallelizes), supports CRD schemas through -schema-location, and offers junit/tap/json output for CI.

### In CI?

kubeconform reads stdin with -, so the kustomize pipeline becomes kustomize build overlay | kubeconform -strict -. Both tools exit non-zero on failure, so the pipeline gate behaves the same after swapping the binary and renaming flags.

### Common errors in CI?

After migrating, could not find schema for <CRD-Kind> appears for custom resources kubeval happened to skip; add their schemas with -schema-location or -ignore-missing-schemas. A double-dash flag like --strict passed to kubeconform errors with flag provided but not defined; kubeconform uses single-dash flags.

---

Latchkey runs CI/CD that repairs its own failures. Agent entry points: https://latchkey.dev/agent.txt, https://latchkey.dev/openapi.json, https://latchkey.dev/llms.txt