Learn DevOps with Advanced, real-world projects, live troubleshooting
NGINX Ingress Controller is retiring. And no, Nginx isn’t dying.

Kubernetes is Retiring NGINX Ingress Controller: What It Actually Means and What You Should Do
Remember the Docker panic of 2020? When Kubernetes announced they were deprecating dockershim, and the internet erupted with “Kubernetes is dropping Docker!” headlines?
Everyone lost their minds. Containers kept running fine. Docker images worked exactly as before. The whole thing was blown way out of proportion.
Well, here we go again.
Last week, Kubernetes SIG Network and the Security Response Committee announced they’re retiring the Ingress NGINX controller by March 2026. And as we have seen it again repeatedly, social media is flooded with “NGINX is dead” and “Kubernetes is abandoning us” hot takes.
No, NGINX is not dead. Kubernetes is just not using it as the default ingress controller anymore. Everyone will still be using NGINX. Stop panicking.
Are you looking to advance your DevOps career?
Join my 20-week Advanced, real-world, project-based DevOps Bootcamp is for you.
NGINX The Web Server Is Not Going Anywhere
NGINX, the web server that powers a massive chunk of the internet, is completely fine. It’s not dying. It’s not being deprecated. It’s not going anywhere.
What’s being retired is the Ingress NGINX controller. This is one specific Kubernetes project that uses NGINX under the hood to route external traffic into your cluster.

When you deploy an Ingress resource in Kubernetes, the Ingress NGINX controller reads that configuration and configures NGINX to handle the actual routing.
It’s the controller that’s retiring. The layer that sits between Kubernetes and NGINX. Not NGINX itself. Not the same thing.
Why This Is Actually Happening
The Ingress NGINX project has been running on fumes with just one or two people maintaining it in their spare time. Security holes kept showing up. They tried building a replacement and begged for help.
Nobody came. So instead of pretending everything’s fine while your clusters are at risk, Kubernetes is being honest and saying, “This thing can’t continue safely, please move on by March 2026.”
Unfortunately, even that announcement failed to generate additional interest in helping maintain the project.
InGate development never progressed far enough to create a mature replacement. It’s also being retired.
So Kubernetes SIG Network and the Security Response Committee exhausted their efforts to find additional support and made the call. Best-effort maintenance will continue until March 2026. After that, no more releases. No bugfixes. No security patches for any vulnerabilities that are discovered.
Your existing deployments will continue to function. Installation artifacts will remain available. But you’re on your own fighting the battle.

What You Should Actually Do
Don’t panic. Seriously. You have options and you have time.
Option 1: Move to Gateway API
Gateway API is the modern replacement for Ingress. It’s what the Kubernetes community has been building as the next generation of traffic management.
It’s more powerful than Ingress. More flexible. More expressive. And actually maintained by an active community.
Gateway API supports advanced routing capabilities that require custom annotations in Ingress. Weighted traffic splitting. Header-based matching. Traffic mirroring. Protocol-specific routing for HTTP, gRPC, TCP, and UDP.
The API just hit v1.4.0 with new features like BackendTLSPolicy for encrypted traffic between gateways and backends. This was something Ingress never properly handled.
It’s role-oriented, meaning infrastructure teams manage Gateway resources while development teams manage Route resources. No more configs where everyone steps on each other’s toes.
Cloud providers are already adopting it. DigitalOcean now ships Gateway API pre-installed in all its Kubernetes clusters, powered by Cilium’s eBPF implementation. Google is pushing it hard with GKE. The ecosystem is moving in this direction.
If you’re starting a new project now, use the Gateway API. Don’t even look at Ingress NGINX.
Option 2: Switch to Another Ingress Controller
If you’re not ready to jump to Gateway API yet, that’s fine. You have until March 2026. That’s over a year from now.
Plenty of other Ingress controllers exist.
- Traefik.
- HAProxy.
- Cloud provider-specific ones like AWS ALB Ingress Controller.
Many of them already support both Ingress and Gateway API, giving you a migration path on your own timeline instead of rushing under pressure.
Traefik even has an NGINX annotation compatibility plugin. You can switch to Traefik with your existing Ingress resources while buying yourself time to properly plan a Gateway API migration.
Here are the available Ingress controllers. Pick one that fits your needs and infrastructure.
What Not To Do
Don’t wait until March 2026 and then panic. No one will come to help you if you ignore it now.
- Start planning, poc the Gateway API in your non-production environments.
- Test how your applications behave with different routing configurations.
- Understand the differences between Ingress and Gateway API resource models.
If you have dozens of Helm charts, multiple environments, CI/CD pipelines, and monitoring built around Ingress resources, migration will take work.
To summarize everything
This isn’t Kubernetes abandoning the community. This is an unmaintained open source project finally admitting it can’t continue safely.
When Ingress NGINX was created early in Kubernetes history, it was one of the only options, and became very popular because of its flexibility, features, and independence 3rd third-party vendors, cloud providers.
But the ecosystem evolved. Gateway API emerged as a better, more standardized approach. Service meshes like Istio and Linkerd provide advanced traffic management.
Ingress NGINX couldn’t find enough maintainers to keep it going. That happens in open source. Projects that can’t sustain contributor interest eventually sunset. It’s better to acknowledge that and move forward than to pretend everything is fine while security vulnerabilities stack up.
What Next?
Gateway API is the future of Kubernetes traffic management. That’s not debatable at this point. Major cloud providers are investing in it. The Kubernetes community is pushing it.
For production deployments running Ingress NGINX today, you’ve got options and you’ve got time. Make a plan. Test your migration strategy. Execute it well before the March 2026 deadline.
This is progress, not the end of the world
