The Kubernetes SIG Network and the Security Response Committee has announced the retirement of Ingress NGINX, one of the most widely deployed ingress controllers in the ecosystem. Best-effort maintenance will continue until March 2026, after which there will be no further releases, bug fixes, or security updates, according to an announcement made at Kubecon NA 2025.
The decision will have significant implications for many organisations running Kubernetes clusters, as Ingress NGINX has been a foundational component for directing network traffic to workloads for many years. The controller became popular early in Kubernetes history due to its flexibility, extensive features, and independence from specific cloud providers.
The announcement post explains that the project has suffered from a maintainer shortage which has ultimately become unsustainable. Ingress NGINX had only one or two people doing development work on their own time, after work hours and on weekends. Efforts to find additional support to make continuing the project viable have failed.
Despite the retirement showing the challenge of maintaining successful open-source software that powers critical infrastructure, the announcement does acknowledge the substantial contribution of Ingress NGINX maintainers, noting that the controller has powered billions of requests in data centres and home laboratories worldwide.
The breadth of Ingress NGINX’s functionality was once considered one of it’s key strengths, but it has evolved into what the project maintainers now describe as insurmountable technical debt. Features such as being able to use arbitrary NGINX configuration directives through “snippets” annotations, initially valued for their flexibility, have come to be viewed as serious security vulnerabilities in the context of modern cloud native software.
There was an attempt to develop a replacement controller – named InGate – but this didn’t generate enough interest or support and didn’t progress past the early development stage. This will also be retired at the same time.
The Kubernetes community is recommending migrating to Gateway API, the modern replacement for Ingress. Gateway API was created to address many limitions of the Ingress specification, and has a role-based design that seperates concerns between infrastructure providers, cluster operators, and application developers. It reached general availability in late 2023. It supports all ingress features, and also natively supports many other features that are only available in Ingress NGINX through annotations. As well as HTTP and HTTPS, the API provides native support for other protocols including TCP, UDP, and gRPC, and also has other advanced features such as traffic splitting and header-based matching without needing vendor-specific annotations.
For organisations that aren’t able to adopt Gateway API, there are other alternative ingress controllers which are still actively maintained, including vendor-supported options from NGINX, Kong, Traefik, HAProxy, and others. These controllers vary in their feature sets, performance characteristics, and governance models.
Cloud native advocate Jimmy Song characterised the announcement as “a pivotal moment in infrastructure evolution” and went on to say that “once infrastructure components can no longer be securely updated, they cease to be assets and become liabilities.” He suggests that the retirement shows that maintenance costs have permanently exceeded the pace of community contributions, particularly given the high flexibility that created an extensive attack surface. Song’s analysis emphasises that the core issue is not declining usage but rather unsustainable maintenance dynamics. He ventures that most users move to Gateway API or other Ingress controllers will take significant migration effort.
He notes that long-term community observation shows most users treated Ingress NGINX as a black box, and the migration to Gateway API or alternative controllers now represents what he terms a hidden migration wave for many clusters. He also suggests that a move to unified and extensible APIs is an emergent pattern for new cloud-native infrastructure projects.
Its retirement is not a failure, but an inevitable result of the system advancing to the next stage.
– Jimmy Song
Networking vendors have positioned the announcement as both validation of Gateway API and a commercial opportunity. NGINX promotes its own NGINX Gateway Fabric as a long-term successor, whilst Kong, Traefik, and others have published migration guidance, emphasising the improved governance and richer policy control of their commercial products. HAProxy have also made a migration tool available to help users move from Ingress NGINX to their product.
The blog post explains that organisations can check if they’re using Ingress NGINX by running the command kubectl get pods --all-namespaces --selector app.kubernetes.io/name=ingress-nginx with cluster administrator permissions. They close out the blog by stating the importance of planning a migration as soon as possible, to keep clusters reliable and secure.
