Ingress NGINX Retirement: Why We Didn't Switch to Gateway API Yet

In November 2025, the Kubernetes project announced that ingress-nginx, the ingress controller running on a significant share of Kubernetes clusters worldwide, would reach end of life in March 2026.

The obvious replacement seemed clear: Gateway API, the successor specification designed to replace the Ingress resource entirely. We looked at it seriously, decided against it, and chose a different path. This whitepaper explains why, what we evaluated instead, and what the migration looked like across our customer base.

What the retirement actually means

The announcement from the Kubernetes project is worth reading carefully, because the first impression is more alarming than the reality.

Existing deployments do not break. Helm charts remain available. Container images stay in the registry. The project will accept no new features, but the code does not disappear.

The real question was this: what happens when a CVE lands after March 2026?

That question answered itself in early 2026, when Chainguard announced they would maintain a security-patched fork of ingress-nginx. That fork provides continued CVE coverage, which reduced the urgency of a full migration significantly. When the first CVE surfaces after the official ingress-nginx project is archived, we will switch our ingress-nginx deployments from the official image to the Chainguard fork, as a bridge, not a solution.

The underlying reality stands: ingress-nginx is no longer being actively developed. Building new infrastructure on it does not make sense. We needed a replacement.

Why we did not migrate to Gateway API

Gateway API, the spec designed to replace the Ingress resource entirely, was the first thing we examined. We looked at it carefully. The verdict: wait, for now.

The reasons are specific, not vague.

The Helm chart ecosystem is often not ready. Many application Helm charts in production today only expose Ingress configuration. A cluster operator cannot just switch the Gateway API on; they would need to fork or patch dozens of upstream charts. The operational overhead is not worth it.

The spec is still moving. Gateway API has existed for five years and had significant changes throughout that period, changes you would always need to catch up on. Implementations like Cilium, Envoy Gateway, and Traefik pick up those changes at different speeds. Running Gateway API in production means managing that drift.

TLS certificate management requires a paradigm shift. With Ingress, cert-manager issues a certificate per namespace, scoped to that Ingress resource. With Gateway API, certificates must be managed via cluster-wide Gateway resources. The mechanism that would restore per-namespace delegation, GEP-1713 (ListenerSets), was still marked experimental until end of February 2026. cert-manager documented this clearly.

We did not know which Gateway API implementation would become the standard. Committing to one solution and discovering six months later that the broader ecosystem had converged elsewhere, with stronger community, support, and development cadence, was a risk we were not willing to take.

Our conclusion: Gateway API will be the right answer. Not yet. Envoy Gateway, Cilium Gateway, and similar solutions are flagged for re-evaluation once the ecosystem matures.

With Gateway API off the table for now, the question became more focused: which Ingress controller should we run today?

How we evaluated 20+ controllers

We used the Kubernetes Gateway API conformance list as the starting catalog, covering every known Ingress and Gateway implementation. We filtered by two immediate criteria: active community, and a credible path to Gateway API. A controller with no roadmap toward Gateway API would be another dead end in two years. That eliminated roughly half the field immediately: stale projects, alpha-only conformance, single-vendor tools with minimal adoption.

What remained we evaluated across six criteria:

* Exceptions exist: Envoy Gateway has no Ingress implementation, yet passed on all other criteria.

For community health, we looked at GitHub star trajectory, contributor counts via GitHub Insights, and project activity data from insights.linuxfoundation.org. Stagnating contributor counts or declining commit frequency were early-out signals regardless of feature completeness.