The Kubernetes Steering and Security Response Committees announced on January 29th that the widely-deployed Ingress NGINX controller will reach end-of-life in March 2026. Despite widespread reliance on the tool—approximately 50% of Kubernetes users currently depend on it for traffic management—adoption of alternatives remains sluggish, with a Reddit survey showing 44% of respondents still running Ingress NGINX even after the retirement announcement.
The timeline leaves operators with roughly two months to evaluate and deploy replacement solutions. Organizations that delay face a scenario reminiscent of those still operating CentOS Linux after its June 30, 2024 discontinuation date. Chainguard has committed to supporting Ingress NGINX through its EmeritOSS program, though this represents a limited lifeline rather than a comprehensive solution.
Once retired, the project will receive no further maintenance. As the Kubernetes Steering Committee states, There will be no more release bug fixes, security patches, or any updates of any kind after the project is retired.
Security concerns
The vulnerability landscape surrounding Ingress NGINX underscores the urgency of migration. In March 2025, researchers uncovered a set of five vulnerabilities collectively known as IngressNightmare. The most critical flaw carries a CVSS score of 9.8, and according to Datadog, when combined with lower-severity issues, it allows for unauthenticated remote code execution.
The Kubernetes Steering Committee warns that Existing deployments will continue to work, so unless you proactively check, you may not know you are affected until you are compromised. This passive failure mode means organizations relying on Ingress NGINX may remain unaware of their exposure until an active compromise occurs.
Why retire Ingress NGINX?
The retirement decision stems from chronic understaffing. Despite serving tens of thousands of deployments, Ingress NGINX has been maintained by only one or two people working in their spare time. The Kubernetes Steering Committee explains: 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 emphasizes the security implications of continued reliance on the aging tool, stating choosing to remain with Ingress NGINX after its retirement leaves you and your users vulnerable to attack. The organization has determined that technical debt and fundamental architectural limitations make ongoing maintenance untenable, even if additional resources became available.
In a final statement, the Kubernetes Steering Committee notes: 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.
Source: The New Stack