Why Ingress-NGINX Should Have Been Retired – and Why It Lives On Anyway

The announcement by Kubernetes SIG Network to retire Ingress-NGINX was not an operational accident. It was the result of years of structural overload – and it was right. Not convenient, not popular, but necessary. The fact that this retirement is now being cushioned by Chainguard does not change the diagnosis. But it prevents an overdue decision from becoming an operational disaster.

Ingress-NGINX was for a long time the backbone of the Kubernetes ingress world. Available early, flexible, usable everywhere. It was precisely these properties that made it the quasi-standard. And that is exactly where the problem lay. The enormous adoption was in no proportion to the actual maintenance base. Critical infrastructure processing billions of requests was factually carried by a handful of maintainers – often unpaid, often on the side, often under permanent alert readiness.

Technically, it was added that Ingress-NGINX stems from another time. From a phase when Kubernetes was still young and security models were thought pragmatically, not restrictively. Freely definable NGINX snippets, deep interventions in request processing, a powerful controller directly at the perimeter boundary of the cluster – all this was long considered a strength. Today it is considered a risk. Correctly so.

The larger the platform, the more expensive these legacy burdens become. Every new CVE, every incompatibility, every dependency aggravated the situation. At the same time, the ecosystem evolved: specialized ingress controllers, commercial offerings, and above all the Gateway API as the clear architectural successor. Ingress-NGINX was not functionally obsolete, but conceptually outdated.

Against this background, the decision to end the project in an orderly manner was consistent. To continue would have meant making security promises that could no longer be kept. That would have been negligent – towards users, towards Kubernetes itself, and towards the idea of responsible open source governance.

The actual explosiveness, however, lay in the consequences. An archived Ingress-NGINX without patches would have put thousands of productive clusters in a bind. Either immediate migration under time pressure – or the continued operation of an unmaintained ingress controller at one of the most sensitive parts of the architecture. Both are hardly justifiable in regulated environments. At the latest with NIS-2, DORA, and increasing requirements for operational security, an unpatched gateway becomes a compliance problem.

This is where Chainguard comes into play. Not as a savior in shining armor, but as a pragmatic actor. With EmeritOSS, Chainguard takes over the maintenance of ingress-nginx based on the last stable state. No further development, no feature race, no illusion of future viability. Instead: updated dependencies, security fixes, a clearly communicated maintenance approach.

This is important – and for exactly the right reason. This rescue buys time. Time for clean migrations. Time for architectural decisions without pressure. Time to evaluate the Gateway API realistically and introduce it ready for production. Time, instead of hectic emergency measures.

At the same time, EmeritOSS sets a remarkable signal. Open source has so far often known only two states: active or dead. Chainguard establishes a third: stabilized, accounted for, deliberately limited. This is no substitute for sustainable community structures, but a realistic handling of the reality of life for many infrastructure projects.

One should not romanticize anything. Ingress-NGINX remains legacy. Anyone deploying it newly today is making a bad decision. But anyone operating it productively can now plan responsibly instead of reacting panicky. This is real progress.

Shutting down Ingress-NGINX was right. Not just letting it drop is equally right. Together, both decisions show that technological maturity also means ending things in an orderly manner – and not leaving users alone in the process.