Unfortunately, Ingress NGINX is being retired

Yesterday, the Kubernetes contributor community published a blog (Ingress NGINX Retirement: What You Need to Know) [1], and the Kubernetes SIG Network and Security Response Committee announced the retirement of Ingress NGINX. The key points of the announcement include:

• Ingress NGINX will strive to maintain services until March 2026

• No new versions will be released

• No vulnerabilities will be fixed

• No updates will be made for any security vulnerabilities that may be discovered

• The GitHub repository will be set to read-only for reference only

• Existing Ingress NGINX deployments will continue to run, and installation files will remain available

  
  

01 What impacts will there be on Ingress NGINX adopters?

From the perspectives of risk, operations, and architecture:

• Increased Security Risks

  • Although the existing version and installation package will "continue to be available", there will be no security patches or vulnerability fixes after March 2026. In other words, if new vulnerabilities are discovered in the future, such as logical flaws, configuration injection, supply chain attacks, etc., the community will not respond proactively to Ingress NGINX.

  • In fact, a serious vulnerability was recently discovered (e.g., CVE‑2025‑1974, allowing unauthorized RCE / cluster takeover) that has widespread implications.

  • The risk is particularly significant for production environments, externally exposed services, and even internal Ingress controllers with high privilege access.

• Increased Operational Burden

  • While it is "still available", there will be no official support for bug fixes, compatibility issues, or new requirements (e.g., new Kubernetes versions, new features). The operations team will need to bear the responsibility of identifying and fixing issues on their own.

  • Over time, community contributions may also decrease, and documentation, examples, and issue discussions may diminish, which means the "cost of usage" will gradually increase.

  • In environments with SLA, compliance, and security audits, the use of deprecated components may become an audit issue or a risk item.

• Architectural Strategies Need Adjustment

  • If the team continues to choose Ingress NGINX for new projects or future expansions, it means that technical debt is accumulating: you will eventually have to face migration costs, replacement costs, or accept the reality of "inability to respond proactively to security issues".

  • For existing systems using Ingress NGINX, while they may continue to run in the short term, the lack of maintenance in the long term means that the technical path will lag behind in ecological development and functional evolution.

02 What measures can Ingress NGINX adopters take?

The official recommendations for Ingress NGINX:

• Migrate to Gateway API [2]

• If you must continue using Ingress, the Kubernetes documentation [3] lists many alternative Ingress controllers, such as Azure's AKS Application Gateway Ingress Controller, Alibaba Cloud's MSE Ingress, Higress, etc.

  
  

Below, MSE Ingress and Higress are provided as examples, with detailed migration steps:

• Migrate to commercial solutions: https://help.aliyun.com/zh/mse/user-guide/migrate-from-nginx-ingress-to-mse-ingress

• Compatibility notes for migrating to open-source solutions: https://higress.cn/docs/latest/user/annotation/:

• Migrate case from Shisu Cloud: https://mp.weixin.qq.com/s/IexQXTMpQNo4KxjAp05p8w

• Migrate case from Sealos: https://sealos.run/blog/sealos-envoy-vs-nginx-2000-tenants

03 The Origins and Development of Ingress NGINX

Ingress is the friendly way to direct network traffic to workloads running on Kubernetes. (Gateway API is a newer method that achieves many of the same goals.) To make Ingress work properly in a cluster, an Ingress controller must be running. There are many Ingress controllers available on the market to meet the needs of different users and use cases. Some controllers are cloud-provider-specific, while others have broader applicability.

Ingress NGINX is an Ingress controller that was developed as an exemplar implementation of the API in the early days of the Kubernetes project. Due to its high flexibility, rich features, and independence from any specific cloud or infrastructure provider, it became popular quickly. Since then, community groups and cloud-native vendors have created many other Ingress controllers within the Kubernetes project. Ingress NGINX has remained one of the most popular controllers, being deployed across many managed Kubernetes platforms and numerous independent user clusters.

04 Challenges and Efforts

The breadth and flexibility of Ingress NGINX have brought maintenance challenges. Expectations for cloud-native software are constantly changing, exacerbating the complexity of the issues. Some features that were once considered beneficial are now viewed as serious security vulnerabilities, such as adding arbitrary NGINX configuration directives through "code snippets" annotations. The flexibility that was once an asset has now turned into an insurmountable technical debt.

Despite the popularity of the Ingress NGINX project among users, it has faced issues with insufficient maintainers and even struggles to sustain itself. For years, the project has relied on one or two people working in their spare time, developing in their free time and on weekends. Last year, the maintainers of Ingress NGINX announced plans to gradually stop maintaining Ingress NGINX and to collaborate with the Gateway API community to develop a replacement controller. However, even such announcements failed to inspire more people to participate in the maintenance of Ingress NGINX or in developing InGate as its replacement. (The development of InGate never reached a level sufficient to be a mature alternative; it will also be deprecated.)

05 Heartfelt Thanks

As developers in the cloud-native and open-source fields, we deeply understand that the cessation or retirement of open-source projects is often a decision made reluctantly by the community. We sincerely thank the contributors of the Ingress NGINX community for their efforts in creating and maintaining this project. It has provided developers with a stable, generic, and declarative way to access traffic within the cluster, from simple path forwarding to complex reverse proxies, from TLS termination to multi-tenancy isolation. Ingress NGINX has brought the mature concepts of traditional web services into the container world.

We are grateful not just for the code itself, but for the developers behind the scenes who have quietly maintained it.

[1] https://www.kubernetes.dev/blog/2025/11/12/ingress-nginx-retirement/

[2] https://gateway-api.sigs.k8s.io/guides/

[3] https://www.kubernetes.dev/blog/2025/11/12/ingress-nginx-retirement/