By Tabitha Sable (Kubernetes SRC) ,
To prioritize the safety and security of the ecosystem, the Kubernetes SIG Network and Security Response Committee Ingress are announcing the upcoming retirement of NGINX. Best effort maintenance will continue till March 2026. After that, there will be no further releases, no bug fixes, and no updates to resolve any security vulnerabilities discovered. Existing deployments of Ingress NGINX will continue to work and installation artifacts will remain available.
We recommend migrating to one of several options. Consider migrating to Ingress’s modern replacement, the Gateway API. If you need to continue using Ingress, there are several alternative Ingress controllers listed in the Kubernetes documentation. Continue reading for more information about the history and current state of Ingress NGINX, as well as next steps.
About Ingress NGINX
Ingress is a native user-friendly way to direct network traffic to workloads running on Kubernetes. (The Gateway API is a new way to achieve the same goals.) For an ingress to work in your cluster, an ingress controller must be running. There are many ingress controller options available, meeting the needs of different users and use cases. Some are cloud-provider specific, while others have more general applicability.
Ingress NGINX was an ingress controller, developed as an example implementation of the API early in the Kubernetes project history. It became very popular due to its tremendous flexibility, breadth of features, and independence from any particular cloud or infrastructure provider. Since those days, many other ingress controllers have been created within the Kubernetes project by community groups and cloud native vendors. Ingress NGINX remains one of the most popular, deployed as part of many hosted Kubernetes platforms and within countless independent user groups.
History and challenges
The breadth and flexibility of Ingress NGINX has caused maintenance challenges. Changing expectations about cloud native software have also added complexities. What were once considered helpful options have sometimes come to be considered serious security flaws, such as the ability to add arbitrary NGINX configuration directives via “snippets” annotations. Yesterday’s flexibility has become today’s insurmountable technical debt.
Despite the project’s popularity among users, Ingress NGINX has always struggled with inadequate or barely-adequate maintenance. For years, there have been only one or two people doing development work on the project, on their own time, after work hours and on weekends. Last year, the maintainers of Ingress NGINX announced their plans to shut down Ingress NGINX and develop a replacement controller together with the Gateway API community. Unfortunately, that announcement also failed to generate additional interest in maintaining Ingress NGINX or helping develop Ingress to replace it. (Development of the InGate never progressed far enough to produce a mature replacement; it would also be discontinued.)
Current status and next steps
Currently, Ingress NGINX is receiving best effort maintenance. The SIG Network and Security Response Committee has ended our efforts to find additional support to make Ingress NGINX sustainable. To prioritize user safety, we must retire the project.
In March 2026, Ingress NGINX maintenance will be stopped, and the project will be shut down. After that time, there will be no further releases, no bugfixes, and no updates to resolve any security vulnerabilities discovered. The GitHub repository will be made read-only and kept available for reference.
Existing deployments of Ingress NGINX will not be broken. Existing project artifacts such as Helm charts and container images will remain available.
In most cases, you can check whether you use ingress nginx by running kubectl get pods \--all-namespaces \--selector app.kubernetes.io/name=ingress-nginx With cluster administrator permissions.
We’d like to thank the Ingress NGINX maintainers for their work in building and maintaining this project—their dedication remains impressive. This ingress controller has handled billions of requests in datacenters and homelabs around the world. In many ways, Kubernetes would not be where it is without Ingress NGINX, and we are grateful for its incredible effort over so many years.
The SIG Network and Security Response Committee recommends that all Ingress NGINX users immediately begin migration to the Gateway API or another Ingress controller. The Kubernetes documentation lists several options: Gateway API, Ingress. Vendors you work with may have additional options available.