Kubernetes SIG Network and the Security Response Committee have announced the retirement of the Community Ingress NGINX Controller — a decision that will impact a large part of the Kubernetes ecosystem.
“Best effort” maintenance will continue until March 2026. After that, the project will no longer receive updates, bug fixes, or security patches.
While existing deployments will continue to run, they will do so without any security or support guarantees — raising important questions for organizations relying on it in production.
What is changing — and why it matters.
Ingress NGINX has long been a core component for exposing Kubernetes applications.
From March 2026 onward, the Community Ingress NGINX project will no longer receive:
- security patches
- vulnerability remediation (CVE fixes)
- functional updates
Kubernetes SIG Network recommends starting a migration now, either toward the Gateway API or another supported Ingress controller.
From a security and governance perspective, continuing to run an unmaintained component introduces increasing risk over time.
No immediate disruption — but increasing risk.
It’s important to clarify:
applications will not suddenly stop working in March 2026.
However, the situation will evolve progressively:
- no future vulnerabilities will be fixed
- compatibility with future Kubernetes versions becomes uncertain
- security teams lose visibility and control
For critical, exposed, or regulated environments, this quickly becomes a strategic decision — not just a technical one.
What are your options?
Organizations essentially have two main paths.
- Move to the Kubernetes Gateway API
The Gateway API is the long-term direction recommended by Kubernetes. It brings:
- role-oriented architecture
- standardized APIs
- improved portability
Many implementations already exist: https://gateway-api.sigs.k8s.io/implementations/
That said, this is a significant architectural shift, which can be complex for existing environments.
- Adopt a supported Ingress alternative
Community Ingress NGINX is not the only Ingress Controller available.
Several actively maintained alternatives exist, including those listed by Kubernetes: https://kubernetes.io/docs/concepts/services-networking/ingress-controllers/
For teams already using NGINX, F5 NGINX Ingress Controller (OSS) offers a natural and sustainable evolution:
- open source (Apache 2.0)
- actively maintained
- technological continuity
- compatible with future Gateway API adoption
A pragmatic approach to migration.
There is no one-size-fits-all path.
In practice, successful migrations are:
- progressive
- controlled
- aligned with business and security priorities
Most organizations benefit from stabilizing their current environments first, securing them properly, and then planning a gradual transition.
What should you do next?
If you are:
- running Kubernetes or OpenShift in production
- evaluating Gateway API
- or looking to reduce your security exposure
Now is the right time to assess your situation and define a clear migration strategy.
