· ReadyStack
Worked example
Real numbers from this tool, line by line.
Twenty-four findings came out of two Ingress objects, twelve of them errors, in a manifest an AKS platform engineer had been shipping unchanged for a year.
The manifest was not broken. That is the whole problem. ingress-nginx stopped shipping releases and security fixes on 2026-03-01, and a retired controller does not crash — it just stops being the thing anyone patches. Meanwhile the routing rules are still sitting where they always were: in annotations. nginx.ingress.kubernetes.io/rewrite-target. canary-weight. auth-url. whitelist-source-range. Forty-odd lines of YAML that describe how traffic reaches production, written in a dialect that only one unmaintained controller speaks.
Gateway API is where those rules go. Most of them have a home there. rewrite-target becomes an HTTPRoute filter of type URLRewrite, with urlRewrite.path.replacePrefixMatch. canary-weight: "10" becomes a second entry in backendRefs[] with weight: 10. proxy-read-timeout: "120" becomes rules[].timeouts.backendRequest: 120s. upstream-vhost becomes a RequestHeaderModifier that sets Host.
The dangerous ones are the annotations that have no Gateway API core equivalent at all.
In that two-object fixture, five findings say exactly that. auth-url and auth-signin sent every request through an external SSO subrequest; Gateway API core has no external-auth filter, so unless you port it to an implementation extension or a sidecar, the route comes up on the new controller with the auth check simply absent. whitelist-source-range limited who could reach an admin path; there is no core equivalent, so it has to be rebuilt as a NetworkPolicy or an authorization policy.
None of this produces an error. kubectl apply accepts the HTTPRoute. The Gateway reports Programmed. The route serves traffic. The only symptom is a request that should have been refused and was not, and you find that out from someone else.
That is why the check is a rule set and not a prompt. A chatbot asked to translate auth-url into Gateway API will produce a field name, because producing a plausible field name is what it is built to do. Grep will find the annotation but cannot tell you whether a replacement exists. The lint runs 30 fixed rules over the YAML text and returns the same answer twice on the same input, with the line number and the replacement field — or the words *no Gateway API core equivalent*.
Two of those 30 rules are not pattern matches. One takes today's date and counts how many days each kind: Ingress object has been running on an unmaintained controller — 200 days, as of 17 September 2026. The other flags an Ingress with no spec.ingressClassName, an object every controller ignores unless it has appointed itself the cluster default, which is its own quiet way to lose traffic.
Point it at the Gateway API version of the same routing and it returns zero findings. That is the whole acceptance test: migrate until the file is quiet.
The extension lints the file you have open, free, with every finding and every replacement field — no watermark, no counter, no locked result. The full version changes the scope rather than the answer: it sweeps every manifest in the workspace in one pass and writes a migration report file you keep and attach to the change ticket. A freelance Kubernetes consultant bills around $150 an hour, and reading one cluster's ingress manifests annotation by annotation is a day of that.
Free web version, no install: https://getreadystack.com/tools/ingress-nginx-retirement-lint
15 seconds — what it actually does
Questions people ask
What does Ingress-NGINX Retirement Lint actually do?
It reads a Kubernetes Ingress manifest and, for every nginx.ingress.kubernetes.io annotation on it, names the Gateway API field that replaces it — HTTPRoute filters, backendRef weights, route timeouts. When there is no core equivalent, such as external auth or source-range allow lists, it says so and flags the finding as an error rather than a warning.
Who is this for?
Platform and DevOps engineers holding Ingress YAML on AKS, EKS or GKE clusters that still route through ingress-nginx. It is aimed at the person writing the migration change ticket, who has to state which routing behaviour survives the move to Gateway API and which behaviour has to be rebuilt somewhere else first.
Why can't I just ask a chatbot or grep the manifests?
Grep finds annotation names; it does not know which ones have a Gateway API core equivalent. A chatbot will confidently translate an annotation that has no replacement at all, because inventing a plausible field name is exactly what it is good at. This runs a fixed rule set of 30 checks, so the same manifest gives the same answer twice.
What is free and what does the paid version add?
Free lints the file you have open, with every finding, line number and replacement field. That is a complete job — nothing is hidden or watermarked. The full version changes scope and ownership: it sweeps every manifest in the workspace in one pass and writes a migration report file you keep and attach to a change ticket.
What would this cost me otherwise?
A freelance Kubernetes consultant bills around $150 an hour, and reading one cluster's ingress manifests annotation by annotation is roughly a day of that work. The bundled two-object fixture alone returns 24 findings, 12 of them errors, which is the shape of what a reviewer would have to write out by hand.
Why not just ask ChatGPT or another AI chat?
A general AI chat answers from training data with a cutoff date, cannot read your repository and names no rule version. Ingress NGINX Retirement Lint - migrate to Gateway API checks the file you open against 30 rules from a rule set dated 2026-09-20, and points at the exact line with the fix. For a filing, an audit or a client you need that dated result on your own files.
Ask about this tool
One question, answered by the person who built it. Your email only if you want the answer sent.