Kubernetes Ends Ingress NGINX Support in March 2026—and There's No Easy Way Out
The Kubernetes Steering Committee has set a hard deadline for retiring Ingress NGINX, leaving half of all Kubernetes users scrambling to find alternatives with no drop-in replacement available.
On January 29th, the Kubernetes Steering and Security Response Committees delivered a stark message: Ingress NGINX will be retired in March 2026. Despite widespread warnings, the situation remains dire. Currently, 50% of Kubernetes operators depend on Ingress NGINX to handle incoming traffic, yet many have ignored the writing on the wall. A Reddit survey revealed that even after the retirement announcement, 44% of users continued running the software without making changes.
The timeline is unforgiving. Organizations have roughly two months to deploy a replacement solution—or face the consequences of maintaining unsupported infrastructure. This mirrors the predicament of enterprises that continued running CentOS Linux after its June 30, 2024 end-of-life date, hoping vulnerabilities would not be exploited. Chainguard has committed to supporting Ingress NGINX through its EmeritOSS program, but this is not a long-term solution. Organizations considering this path should contact Chainguard immediately.
The stakes are high. According to the Kubernetes Steering Committee, "There will be no more release bug fixes, security patches, or any updates of any kind after the project is retired." This means organizations will be entirely on their own.
Security concerns
Ingress NGINX occupies a critical role in most Kubernetes deployments, making its vulnerability profile particularly alarming. The software has demonstrated a pattern of security weaknesses. In March 2025, researchers uncovered a set of five vulnerabilities collectively known as "IngressNightmare." One flaw stood out as especially dangerous. Security firm Datadog characterized it as "considered the most serious of the five and has been assigned a CVSS score of 9.8 (critical). When chained with one of the lower-severity vulnerabilities, it allows for unauthenticated remote code execution."
The Kubernetes Steering Committee has issued a troubling warning: "Existing deployments will continue to work, so unless you proactively check, you may not know you are affected until you are compromised." Organizations may discover they have been breached only after an attack has already occurred, making proactive migration essential.
Why retire Ingress NGINX?
The retirement decision stems from a fundamental resource crisis. Open-source projects often begin as solutions to individual problems, but those adopted by tens of thousands of organizations require sustained investment in funding, development, and maintenance. Ingress NGINX had virtually none of this. Toward the end, the project was maintained by only one or two people working in their spare time.
The Kubernetes Steering Committee explained the situation plainly: "it has been maintained solely by one or two people working in their free time. Without sufficient staffing to maintain the tool to a standard both ourselves and our users would consider secure, the responsible choice is to wind it down and refocus efforts on modern alternatives like Gateway API." The committee added bluntly, "To be abundantly clear: choosing to remain with Ingress NGINX after its retirement leaves you and your users vulnerable to attack."
The committee emphasized that this decision was not made hastily. "We did not make this decision lightly; as inconvenient as it is now, doing so is necessary for the safety of all users and the ecosystem as a whole. Unfortunately, the flexibility Ingress NGINX was designed with, which was once a boon, has become a burden that cannot be resolved. With the technical debt that has piled up, and fundamental design decisions that exacerbate security flaws, it is no longer reasonable or even possible to continue maintaining the tool even if resources did materialize."
No white-knight rescue is coming. Organizations that have delayed migration decisions will face the difficult choice between maintaining unsupported software independently or migrating to alternatives—none of which offer a straightforward replacement path. The responsibility for managing this transition now rests entirely with users.
Source: The New Stack