Kubernetes manifest analyzer

Paste a Kubernetes manifest to find missing resource limits, risky security settings, overly broad RBAC rules, and get a suggested patch.

Runs in your browser ยท nothing is sentKubernetes & IaCNew

Everything runs in your browser. Nothing is sent anywhere, including image names, namespaces and labels in your manifest.

How to use

  1. Copy a manifest with "kubectl get deployment <name> -o yaml" or from your source files.
  2. Paste the YAML into the tool (use "---" between documents if you have more than one).
  3. Review the findings and the resource table.
  4. Open "Suggested changes" for a patch to merge into your manifest, then export the report if needed.

Common scenarios

Reviewing a Deployment before it goes to production

Check whether resource limits, probes and a safe security context are all in place before merging a manifest.

Auditing RBAC before granting a new role

Paste a Role or ClusterRole to check for wildcard permissions or Secret access before binding it to a service account.

About this tool

Paste one or more Kubernetes manifests (separated by "---" if there are several) and the tool checks every workload (Pod, Deployment, StatefulSet, DaemonSet, Job, CronJob) for missing resource limits and requests, a missing or risky security context (privileged containers, allowed privilege escalation, a writable root filesystem, dangerous Linux capabilities), missing liveness and readiness probes, and an unpinned image tag. It also checks every Role and ClusterRole for overly broad RBAC rules, such as a wildcard on both resources and verbs, or read access to Secrets. For each container with something missing, it suggests a patch you can merge into your manifest. Everything runs locally; the manifest never leaves your browser.

๐Ÿ”’ Your input stays in your browser and is never sent anywhere.

Frequently asked questions

Does this validate against the Kubernetes API or a cluster?

No. It only parses the YAML you paste and checks it against a fixed set of rules, without connecting to any cluster or API server.

Why is a missing "runAsNonRoot: true" flagged even if the image already uses a non-root user?

Without the explicit setting, Kubernetes allows the container to run as root if the image is ever changed to one that defaults to root, intentionally or not. Setting it explicitly makes that mistake impossible rather than merely unlikely.

What does the suggested patch include?

Only the fields this tool actually checks: resource requests and limits, a safer security context, and example liveness/readiness probes. The example values (especially resource limits) are starting points, not a measurement of your workload, so adjust them to what the container actually needs.

Does it support CronJob and multi-document files?

Yes. CronJob is checked through its nested jobTemplate, and you can paste several documents separated by "---", including a mix of workloads and RBAC resources.

What to do next

Also useful

Found a problem or have a suggestion? Tell us