The Ingress NGINX Retirement Created Three Risks. Most Teams Are Only Managing One.

The retirement of Ingress NGINX is official. As of March 24, 2026, there are no more releases, no more bug fixes, and no more security patches. Roughly half of all cloud-native environments are running a controller that will never be updated again. The urgency of the situation is not in question.

What is in question is whether the response to that urgency is complete.

The Ingress NGINX retirement did not create one risk; it created three. The first is migration risk: the operational challenge of moving hundreds of clusters off a retired controller without breaking production. The second is security risk: the architectural question of whether the new controller eliminates the vulnerability class that made Ingress NGINX untenable, or inherits it. The third is stagnation risk: the strategic question of whether the foundation being laid today can support the governance layers every organization will need to build on top of it over the next several years.

The migration conversation happening across the Kubernetes community right now is almost entirely focused on the first risk. The other two deserve equal attention. The decisions being made now will compound, for better or worse, across all three.

Migration Risk

Migration risk is the risk most teams understand best, because it is the most immediately visible. Clusters running Ingress NGINX today are running unmaintained software. Every day that passes is a day closer to an unpatched CVE landing in a production environment with no fix available. The operational pressure to move is real and justified.

But migration risk is not just about urgency. It is about what the migration actually requires in practice, and that is where most of the market response has fallen short.

When the Ingress NGINX retirement was announced, vendors responded by positioning their controllers as the destination. Compatibility tables appeared. Blog posts explained why each vendor's product was the natural landing spot. The conversation became: which controller should we migrate to?

That framing misses the harder problem. Ingress NGINX users have built configurations over years using a specific annotation vocabulary. Some of those annotations have direct equivalents in other controllers. Some require behavioral substitutes. Some require rethinking routing logic entirely. For a team running a handful of clusters, that is a manageable audit. For a team running hundreds, it is a multi-quarter engineering project, unless someone has already built the bridge.

Traefik built the bridge. The open-source Ingress NGINX migration tool, available at github.com/traefik/ingress-nginx-migration, analyzes existing cluster configurations, maps annotations against Traefik's Ingress NGINX Provider, identifies gaps, and generates a migration report before any commitment is made. Traefik's Ingress NGINX Provider covers over 90% of Ingress NGINX annotations, meaning the vast majority of existing configurations migrate without manual rewriting.

This reflects a long-view approach to winning in this market: solve the actual engineering problem teams are facing, and earn the adoption that follows. Not a destination to land on. A bridge to get there without operational disruption.

Migration risk is real and solvable. It is also the least consequential of the three risks if the other two go unaddressed.

Security Risk

Security risk is the risk the migration conversation has most conspicuously skipped. It is also the one with the most structural teeth.

The IngressNightmare vulnerabilities, including CVE-2025-1974 scored at 9.8 critical, allowed unauthenticated remote code execution through a memory handling flaw in the admission controller. The root cause was not a logic error or a misconfiguration. It was a structural property of C: a language model that puts memory management responsibility on the programmer, where any developer under any level of pressure can introduce a buffer overflow, use-after-free, or heap overflow that an attacker can turn into full cluster compromise. No amount of code review, fuzzing, or static analysis permanently eliminates this class of vulnerability. It can be found and patched. It cannot be architected away.

The vulnerability class that made Ingress NGINX untenable is not specific to Ingress NGINX. It is specific to C and C++. A replacement controller written in C or C++ with active commercial support is a better operational situation. It is not a different security architecture. The exposure is managed through ongoing vigilance rather than eliminated through language-level guarantees.

The US government has formalized this position across a series of joint publications by the NSA, CISA, the FBI, and the cybersecurity agencies of the UK, Australia, Canada, and New Zealand, including the NSA's Software Memory Safety guidance, The Case for Memory Safe Roadmaps, and the Memory Safe Languages guide published in June 2025. In October 2024, CISA and the FBI attached a deadline: publish a memory safety roadmap by the end of 2025 or be in a position described as "dangerous and significantly elevating risk to national security." Rather than soften that position after industry feedback, they published a Version 2.0 in January 2025 incorporating responses from 78 public comments and adding further context to the memory safety section. The end of 2025 deadline was held. Among every C and C++ ingress controller on the official Kubernetes documentation page, not one published a roadmap.

The deadline has since passed. 

77% of the self-hosted ingress controllers listed on the official Kubernetes documentation page carry C or C++ memory safety exposure with no published remediation roadmap.

Traefik Proxy is written in Go, which is on the NSA and CISA approved memory-safe language list. Go's garbage collector makes use-after-free structurally impossible. Go's bounds checking makes buffer overflow structurally impossible. These are not mitigations. They are language-level guarantees that remove the vulnerability class from the possibility space entirely. Traefik Proxy has no memory safety debt, and therefore no roadmap to publish.

Beyond memory safety, Go's new Green Tea garbage collector (default since 1.26) further closes the performance gap achieving 10–40% less GC overhead, all with sub-100µs pauses and zero tuning knobs.

A migration that lands on a Go-native controller addresses migration risk and security risk in a single motion. A migration that lands on a C or C++ controller addresses migration risk and defers security risk to a future CVE cycle.

Stagnation Risk

Stagnation risk is the risk almost nobody is talking about. It is also the one with the longest tail.

Ingress NGINX retirement is forcing a migration decision today. But the ingress controller is not the destination. It is the first step. Every organization running Kubernetes at production scale follows a predictable architectural evolution, and the controller chosen today will either support that evolution or constrain it.

Traffic enters through the ingress layer. As application complexity grows, an API gateway becomes necessary to centralize authentication, rate limiting, routing policy, and API lifecycle management. As security requirements mature, WAF capability provides protection against application-layer attacks. As AI workloads arrive, an AI gateway governs token costs, content policy, model routing, and inference guardrails. As agents and agentic systems move into production, MCP governance controls which tools agents can call, under what permissions, and according to what policy constraints.

Each of these is a layer of runtime governance. Each one needs to be deployed, configured, and maintained. And here is where stagnation risk becomes concrete: if each layer requires a separate product from a separate vendor on a separate control plane, the operational overhead compounds with every gate added. If adding WAF capability means ripping out the ingress layer and replacing it with something else, the organization paid the migration cost twice. If the AI gateway requires a different data plane than the API gateway, the security posture of the two layers cannot be governed consistently.

Stagnation risk is the risk of building the governance architecture on a foundation that cannot grow with it.

Traefik addresses stagnation risk through an architecture built specifically for this evolution. Traefik Proxy is the ingress layer. Traefik Hub extends it, through Helm chart upgrades, to API gateway with integrated Coraza WAF, to AI gateway with NVIDIA safety guardrails and token governance, to MCP gateway with TBAC-based agent access control, and to full API management with GitOps-driven lifecycle management. A single binary. A unified control plane. The Triple Gate Pattern: API Gateway as Gate 1, AI Gateway as Gate 2, MCP Gateway as Gate 3, each adds a layer of runtime governance on the same Go-native, memory-safe foundation.

This means the organization that migrates to Traefik today does not pay a migration cost again when it adds WAF. It does not adopt a new vendor when it needs AI governance. It does not rearchitect the data plane when agents arrive. Each capability is a Helm upgrade on the same foundation. The stagnation risk collapses to near zero because the journey was planned for from the beginning.

This is the difference between a destination decision and a journey decision. Destination thinking asks: which controller should we land on? Journey thinking asks: which foundation can we build everything that follows on top of, without paying again for decisions we already made?

A Further Dimension for European Organizations

For organizations operating in European markets, all three risks carry an additional regulatory layer with hard dates. The EU Cyber Resilience Act, which entered into force in December 2024, requires that products with digital elements be designed with security from the outset, with secure coding practices as a design-phase requirement. Vulnerability reporting obligations become mandatory on September 11, 2026. Full compliance, including the requirement that non-compliant products cannot be sold in the EU market, takes effect on December 11, 2027. An ingress controller sits directly in the path of traffic to products subject to CRA compliance. The language-level security posture of that controller is inside the compliance perimeter. The end of 2025 CISA deadline has passed. The September 2026 CRA reporting deadline is six months away.

All Three Risks Are Addressable. Now Is the Time.

The Ingress NGINX retirement created a forcing function. Teams are doing the work regardless: auditing clusters, mapping configurations, planning cutovers. The operational investment is already in motion.

That investment is the reason now is exactly the right time to address all three risks, not just one. The incremental cost of choosing a Go-native, journey-ready controller over a C or C++ alternative is close to zero at the point where the migration is already running. The long-term cost of not making that choice accumulates with every security advisory, every compliance review, and every governance layer that has to be rebuilt on a foundation that was not designed for it.

Migration risk: addressed by the Traefik Ingress NGINX migration tool, the 90%+ annotation coverage of the Ingress NGINX Provider, and the step-by-step migration guide at ingressnginxmigration.org.

Security risk: addressed by Traefik Proxy's Go-native architecture, which eliminates the memory safety vulnerability class by design, with no debt and no roadmap required.

Stagnation risk: addressed by Traefik Hub's unified platform, which extends from ingress to API gateway, WAF, AI gateway, MCP governance, and API management through Helm upgrades on a single binary and a single control plane.

Three risks. One foundation. The migration is the right time to address all of them.

Ready to start? Run the open-source migration tool at github.com/traefik/ingress-nginx-migration and generate your compatibility report in minutes. For enterprise migrations at scale, Traefik Labs provides dedicated migration support at traefik.io/solutions/oss-support.