Will this container take down its whole node?

Paste or load Kubernetes manifest YAML and get a deterministic report of every container missing a memory limit, memory request, CPU request, or ephemeral-storage limit -- the specific gaps that let one container starve or crowd out everything else sharing its node.

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)

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

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

node cli.mjs check manifests.yaml                    # list every finding, exit 0 (informational)
node cli.mjs check manifests.yaml --fail-on-risk     # exit 1 if any container is left unbounded or invalid
node cli.mjs check manifests.yaml --fail-on-risk --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

Six checks, run against every container and init container in every Pod, Deployment, StatefulSet, DaemonSet, ReplicaSet, Job, and CronJob it finds: a missing memory limit or request, a missing CPU request, a missing ephemeral-storage limit, a CPU limit (reported informational, not a problem — see below), and a request set above its own limit for CPU or memory. See why each one matters for the exact Kubernetes mechanism behind it, sourced from Kubernetes' own documentation rather than assumed.

It cannot see what a container actually uses at runtime — only what the manifest declares — so it cannot tell you whether a number you did set is the right number, only whether one is present and internally consistent. Pair it with kubectl top or your metrics stack for that. Already using Polaris from Fairwinds? See how this checker differs. Wondering whether a visual review of the YAML already covers this? See this checker vs. reading the manifest by eye. Checking a chart rendered by Helm specifically? See Helm Values Schema Check. A manifest passing this check can still drop live traffic during a rollout for reasons that have nothing to do with resource limits — see Kubernetes Rollout Safety Check for readiness probes, PodDisruptionBudgets, and termination grace periods, and Kubernetes Deprecated API Check for whether the manifest survives your next cluster upgrade at all.

Common questions

Why does a missing resource limit matter if my container has never had a problem?

Because the failure a missing limit invites is not gradual, it is a threshold: nothing looks wrong until the node runs low on memory or disk, and then the kubelet's eviction or the kernel's OOM killer acts -- and neither of those is scoped to only the container that grew. A container running fine today with no memory limit is one noisy neighbour away from taking others down with it.

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.

Why is a CPU limit reported as informational instead of a problem to fix?

Because, unlike the other findings here, a CPU limit is not simply missing something safer -- once set, it is enforced by the kernel's CFS bandwidth controller, which can throttle a container that bursts within one scheduling period even while the node overall has spare CPU. That is a real, well-documented trade-off (tracked upstream as kubernetes/kubernetes#67577), not a bug, so this tool surfaces it rather than telling you to remove it.