ingress-nginx retires in March 2026, pushing Kubernetes users toward Gateway API

ingress-nginx winds down with no successor

The Kubernetes project has announced that ingress-nginx retires in March 2026, after which the controller receives no further patches or updates. No successor was named; the recommendation is to migrate to Gateway API. According to a migration guide published on dev.to, the cause is a shortage of maintainers — for years the project was effectively a spare-time effort sustained by one or two people.

A replacement controller called InGate was planned in collaboration with the Gateway API community after the retirement announcement, the article explains, but no contributors stepped up and InGate was retired as well. The author is blunt about why the announcement names no replacement: there was no viable project to name.

Existing deployments will not break overnight. Helm charts and container images remain usable, but security fixes stop arriving. When new vulnerabilities are found they will go unpatched, so the system keeps working while the unfixed exposure quietly grows.

Gateway API is a specification, not software

The biggest conceptual shift is that Gateway API is a Kubernetes specification rather than a program. In the Ingress era, applying an Ingress manifest worked because ingress-nginx — the near-universal implementation — was already installed, and the spec and its implementation were effectively the same thing. An HTTPRoute applied to a cluster with no Gateway controller installed does nothing. Migrating to Gateway API therefore means picking and installing an implementation, turning what used to be an implicit decision into an explicit one.

Too many implementations, no default

The options are numerous. Within the Envoy-based family alone the article lists Envoy Gateway, kgateway, Istio, Contour and Cilium; outside it sit Traefik, Kong and NGINX Gateway Fabric, plus each cloud provider's own offering. All claim Gateway API conformance, but the dev.to piece gives three reasons why that does not make them interchangeable.

First, conformance levels vary: Gateway API features are split into Core, Extended and Implementation-specific tiers, and claiming conformance only requires Core support. Second, the features production systems actually need — authentication, rate limiting, circuit breaking — tend to live in Extended or Implementation-specific territory, expressed through vendor resources such as Envoy Gateway's SecurityPolicy CRD or Istio's AuthorizationPolicy. Writing one of those resources locks you into that implementation. Third, there is no default anymore: ingress-nginx used to be the go-to option, and now every team faces the same decision at once without a settled answer.

How the main options compare

The article compares four implementations. Envoy Gateway pairs an Envoy data plane with good migration ease, excellent extended feature coverage and strong momentum as a CNCF incubating project. Istio is the only option with full service mesh support, including east-west traffic control and sidecar injection; it rates moderate on migration ease because the mesh stack is a prerequisite, and it is CNCF graduated with excellent momentum. Traefik runs its own data plane, handles basic routing well and shows good momentum. NGINX Gateway Fabric rates excellent on migration ease because it shares the same nginx data plane as ingress-nginx, but has a lower release cadence and moderate momentum.

The author deliberately makes no recommendation, arguing the right answer depends on whether you already run a service mesh, how costly an annotation rewrite would be, and whether your team has operational experience with Envoy.

Sort annotations into three categories

The practical method the article proposes is an annotation inventory sorted into three categories. Category A covers annotations that migrate directly to standard Gateway API resources; path rewrites are the worked example, where an ingress-nginx regex pattern such as /api(/|$)(.*) with a rewrite-target of /$2 maps to equivalent standard HTTPRoute configuration. Category B covers features that cannot be expressed in the standard spec, such as external auth and rate limiting, and requires implementation-specific resources. Category C is judged line by line rather than annotation by annotation: a single configuration-snippet can mix lines that belong to Category A with lines that require Category B.

Before and after manifests plus validation scripts accompany the article in a public repository. Envoy Gateway and Istio were chosen for the implementation-specific examples because their extensions cover the most ground, while Traefik and NGINX Gateway Fabric, though capable of basic routing, have less mature vendor extensions.

Why it matters

ingress-nginx was the implicit default for serving HTTP traffic on Kubernetes; its retirement removes that default and turns ingress routing into an explicit architectural decision. Staying put is not a stable option, because the end of security patches turns an untouched deployment into a slowly growing liability. And since the features teams rely on most, such as authentication and rate limiting, often sit outside the Gateway API Core spec, the first implementation choice tends to be sticky. Teams that inventory their annotations now and separate the standard from the vendor-specific can make that choice deliberately instead of inheriting lock-in by accident.