Will this manifest survive your next Kubernetes upgrade?

Paste or load Kubernetes manifest YAML and get a deterministic report of every apiVersion + kind pair a past or future Kubernetes release has removed -- extensions/v1beta1 Ingress, batch/v1beta1 CronJob, policy/v1beta1 PodSecurityPolicy, and more.

Nothing is uploaded. The file you load is read in this browser and never leaves your device. No kubeconfig, no API server call.

1. Load your manifests

From a file (raw YAML, or the output of helm template / kustomize build -- read locally, never uploaded)

…or paste it directly (one or more ----separated documents) Target Kubernetes version (optional — e.g. 1.25)

Prefer a CLI, or want this as a CI gate before you upgrade?

Same table, zero dependencies, one file — run it against your manifest repo or your Helm/Kustomize render output:

node cli.mjs check manifests.yaml                              # list every known deprecated/removed API, exit 1 if any found
node cli.mjs check manifests.yaml --target-version 1.25        # exit 1 only if 1.25 would reject one of them
node cli.mjs check manifests.yaml --target-version 1.25 --strict --json

Get cli.mjs — Node 18+, nothing to install. It reads only the local file you name: no network call, ever.

What this checks — and what it cannot

The table below is sourced from Kubernetes' own Deprecated API Migration Guide, not guessed. It lists apiVersion+kind pairs across the four release waves that removed something (1.16, 1.22, 1.25, 1.26).

Already using Pluto from FairwindsOps? See how this checker differs — short version: same question, different install cost. Prefer to just read the guide and check by hand? See why that gets one apiVersion like extensions/v1beta1 Ingress wrong even when the rest of a check is correct. A manifest passing this check can still drop live traffic during the rollout itself for reasons that have nothing to do with a removed API — see Kubernetes Rollout Safety Check for readiness probes, PodDisruptionBudgets, and termination grace periods. Checking a chart rendered by Helm specifically? See Helm Values Schema Check for whether its values.yaml actually matches its own values.schema.json before you even render it. A manifest that survives the upgrade and drops no requests on rollout can still let one container starve or crowd out its whole node — see Kubernetes Resource Limits Check for missing memory/CPU/ephemeral-storage requests and limits.

Common questions

Does this catch every deprecated Kubernetes API?

No. It checks against a table of apiVersion+kind removals that Kubernetes' own Deprecated API Migration Guide documents with a fixed release number — currently the 1.16, 1.22, 1.25 and 1.26 removal waves. It deliberately does not guess at future or in-progress deprecations it cannot cite a release number for. Treat a clean report as one more gate passed, not a guarantee your manifests will survive every future upgrade.

Is my manifest uploaded anywhere?

No. The browser page parses a pasted or locally loaded file entirely in your own browser and never sends it anywhere. The CLI reads only a local file — no network call, ever.

Does this need a kubeconfig or talk to my cluster?

No. It reads only the YAML text you give it. It has no kubeconfig, makes no API server call, and needs no cluster access at all — that is what makes it safe to run against production manifests in CI.

Does it understand Helm charts or Kustomize overlays?

Not directly — it reads plain YAML documents, not Helm template expressions or Kustomize patches. Run helm template or kustomize build first and check the rendered output, the same manifest your cluster would actually receive.