Skip to content

Goodbye to Ingress NGINX – What Happens Next?

The Kubernetes community has officially started the countdown to retire Ingress NGINX, one of the most widely used ingress controllers in the ecosystem.

SIG Network and the Security Response Committee have announced that Ingress NGINX will move to best-effort maintenance until March 2026, after which there will be no new releases, no bug fixes, and no security updates. 

At the same time, the broader networking story in Kubernetes is evolving: Gateway API is now positioned as the successor to Ingress. In this blog, we describe why this is happening, when a replacement make sense, and how/when you should migrate.

Why Is Ingress NGINX Being Deprecated

A few overlapping forces pushed the community to retire Ingress NGINX.

1. Chronic Maintainer Burnout

For years, Ingress NGINX was effectively maintained by one or two volunteers, largely in their spare time. That’s a brutal model for something that sits directly on the edge of thousands of production clusters. Eventually, the responsible thing to do was to stop pretending this was sustainable and set a clear end-of-life timeline.

T Hockin Response

2. Security Incidents and Risk Profile

In 2025, a serious vulnerability CVE-2025-1974 underscored just how dangerous it is to have a heavily-used, under-resourced edge component. Ingress NGINX’s flexibility especially around things like arbitrary snippet annotations — was once seen as a superpower. Over time, those same capabilities turned into hard-to-reason-about attack surface, making it increasingly difficult to secure. 

The conclusion CNCF came to was to protect the broader ecosystem. This meant that Kubernetes should stop investing in a controller with too much legacy baggage and too few maintainers.

3. The Ecosystem Has Moved On!!!

Ingress NGINX was created when the Ingress API was the only option. Since then, modern requirements have evolved—such as multi-tenancy, advanced routing (headers, canaries, multi-protocol), service mesh integration, and clearer separation of infrastructure and application concerns.

The Kubernetes community responded by designing the Gateway API, a more expressive, role-oriented, and extensible standard.

Once Gateway API hit v1.0 GA and gained multiple high-quality implementations, it no longer made sense to cling to a legacy controller that couldn’t evolve safely. 

Is the Ingress API Itself Deprecated?

The short answer:

The GA Ingress API (networking.k8s.io/v1) is not deprecated and remains fully supported in Kubernetes.
The deprecation applies specifically to the ingress-nginx controller, not the Ingress API itself.

What Are Good Replacements for Ingress NGINX?

At a high level, you have three options:

Option 1: Migrate to Another Controller

Below are the available options within the CNCF ecosystem:

Project / Controller Ingress API Support Gateway API Support CNCF Status Comments / Focus
Envoy Gateway ❌ Gateway-native ✅ Native Gateway API CNCF (Envoy is graduated) Pure-play Gateway implementation; ideal for greenfield or Gateway-first adoption
Kgateway ❌ Gateway-native ✅ Gateway API CNCF Sandbox Designed for API gateway and AI-gateway use cases
Contour ✅ Ingress (via Envoy) ✅ Gateway API CNCF Incubating Hybrid controller supporting both Ingress and Gateway; not a pure Gateway implementation
Traefik ✅ Ingress ✅ Gateway API (built-in provider) CNCF Sandbox Hybrid controller; supports dual APIs and enables gradual migration

Option 2: F5/NGINX Ingress Controller

If you prefer to stay in the NGINX ecosystem, F5/NGINX maintains its own open-source NGINX Ingress Controller, which is positioned as a long-term, fully supported alternative to the community ingress-nginx controller.

You can continue using the networking.k8s.io/v1 Ingress API, or adopt Gateway API using NGINX Gateway Fabric, their Gateway-native implementation for more advanced scenarios.

Info

If you unfortunately are a user of nginx-specific annotations, the most realistic short-term solution is probably Traefik, because it now includes support for nginx-style annotations through their brand new ingress-nginx provider.

Option 3: Service Mesh

If you're already using a service mesh, the simplest path is to leverage the ingress controller that the mesh provides natively.

  1. Istio
  2. Cilium
  3. Linkerd

All of these options support both the Ingress API and the Gateway API, so you can continue using Ingress where needed while adopting Gateway API for new applications or greenfield deployments.

How and When Should You Migrate?

For the migration of the controller from "Ingress NGINX" to "Alternative controller", your timeline essentially looks like the following:

Timeline Status / Description
Now – March 2026 Ingress NGINX is on best-effort maintenance. Critical issues may be addressed, but there are no guarantees.
After March 2026 No more releases, bug fixes, or security patches. The project is fully EOL — you’re on your own.

Realistically, if you’re running this in production, you want to be off Ingress NGINX well before March 2026 so you’re not doing emergency edge migrations under pressure.

Step 1: Decide What You Are Migrating Away From

Before choosing a path, determine whether you plan to:

  1. Migrate away from both the Ingress API and the ingress-nginx controller, or
  2. Keep using the Ingress API for now and only replace the controller.

This choice determines how much change you take on and how quickly.

Step 2: If You’re Moving Away From Both Ingress API and ingress-nginx

Migrating fully to the Gateway API requires creating new Gateway resources (Gateway, HTTPRoute, etc.), so it cannot happen in a single cutover. If you choose this path, follow a structured phased migration:

  • Stand up Gateway API and your chosen Gateway controller
  • Create equivalent Gateway resources for your existing Ingress definitions
  • Run Ingress and Gateway in parallel while you validate routing
  • Gradually transition traffic to the Gateway setup
  • Decommission ingress-nginx once all traffic has moved

Info

The folks at Traefik have open sourced a migration tool

Step 3: If You Only Want to Replace the Controller

If you're not ready to leave the Ingress API yet, the simpler option is to switch to a controller that supports both Ingress and Gateway API. This lets you:

  • Keep all your existing networking.k8s.io/v1 Ingress resources
  • Replace ingress-nginx with a modern, supported controller
  • Adopt Gateway API incrementally over time without disruption

Controllers that support both APIs include Traefik and Contour in the CNCF ecosystem.

In short: decide whether you want to migrate API + controller together, or start by only replacing the controller. Your timeline and complexity will differ significantly depending on which path you choose.

Final Thoughts

The deprecation and EOL of Ingress NGINX is definitely disruptive to adopters. But, it is also an opportunity to adopt a more secure, maintainable, and future-proof networking model.

TL;DR for our customers: "Just solve the immediate ingress problem. Migrate to Gateway API on your own timeline with a plan. This is not a crisis!".

  1. Treat Ingress NGINX as on borrowed time.
  2. Treat networking.k8s.io/v1 Ingress as “stable legacy” i.e. perfectly fine for simple use cases, but not where new capabilities will land.
  3. Treat Gateway API as the new standard and the safest place to invest for the next decade of Kubernetes networking.