Ingress NGINX Is Retiring: How to Choose a Replacement
TL;DR
Our two recommendations:
- “I need to migrate off ingress-nginx with minimal disruption” → Traefik with the NGINX Ingress Provider. Deploy it, point it at your existing Ingress resources, and plan your Gateway API migration for later.
- “I want to align with the future of Kubernetes networking” → Envoy Gateway. Use the ingress2gateway tooling to convert your manifests, and accept the upfront migration cost for long-term alignment with the Kubernetes networking direction.
If neither fits your situation, we cover F5 NGINX Ingress Controller, HAProxy, Contour, Kong, and Istio further down.
The Long Version
In November 2025, Kubernetes SIG Network and the Security Response Committee announced the retirement of the ingress-nginx controller, effective March 2026. After that date: no releases, no bug fixes, no security patches.
For ISVs shipping software into customer-managed Kubernetes clusters, this is an urgent dependency problem. If your application embeds or depends on ingress-nginx for routing, your customers will be running unmaintained software in a security-critical position. And if you’ve ever dealt with IngressNightmare (CVE-2025-1974, CVSS 9.8), you know exactly how critical that position is.
If you’re a platform team migrating your own cluster, you have the luxury of choosing one controller and executing a migration plan on your own timeline. ISVs face tighter constraints:
- Customer diversity: Your customers run everything from EKS to bare-metal VMs. Some will have an ingress controller already; others expect you to provide one.
- Annotation dependencies: If your Helm charts use nginx.ingress.kubernetes.io/* annotations, every single one needs to either translate cleanly or get rewritten.
- Bundling vs. requiring: Do you ship an ingress controller as part of your application, or do you document a requirement and let customers bring their own? Ingress NGINX’s retirement means you can no longer defer this decision.
Our Top Recommendations
Based on our testing, for ISVs migrating off ingress-nginx, two controllers stand out.
Traefik — The Closest Thing to a Drop-In Replacement
Traefik is our top recommendation for teams that need to move quickly with minimal manifest changes.
Starting with Traefik Proxy v3.5, Traefik ships an NGINX Ingress Provider that natively understands nginx.ingress.kubernetes.io/* annotations. This is a compatibility layer built into the controller — not a migration tool or annotation mapping guide. Your existing Ingress resources work without modification in most cases.
Why we like it:
- According to Traefik Labs, the NGINX Ingress Provider covers roughly 80% of real-world annotation usage out of the box, and community contributions continue closing the gap.
- Traefik also provides a migration analysis tool that scans your cluster and reports which annotations will translate cleanly and which need attention.
- Full Gateway API support is built in, giving you a clear path from “get off ingress-nginx now” to “adopt Gateway API when you’re ready” without switching controllers again.
- It’s a widely adopted open-source project with a large community, commercial backing from Traefik Labs, and an active release cadence.
- The architecture avoids the text-based templating approach that made ingress-nginx vulnerable to injection attacks.
The catch: The NGINX Provider covers most common annotations, but not all. If you rely heavily on custom snippets, ModSecurity integration, or less common annotations, you’ll need to validate your specific configuration. Traefik’s documentation clearly lists supported and unsupported annotations.
For ISVs: This is the strongest option if you ship Helm charts that currently use ingress-nginx annotations. You can migrate your charts to support Traefik’s NGINX Provider with minimal changes. Your customers deploy Traefik without touching their existing Ingress resources. The two-phase migration approach (swap controller now, adopt Gateway API later) maps well to how enterprise customers plan infrastructure changes.
Envoy Gateway — The Gateway API-Native Choice
If you’re willing to invest in a full migration to Gateway API resources (HTTPRoute, Gateway, GatewayClass), Envoy Gateway is the strongest Gateway API implementation.
Envoy is a CNCF graduated project that underpins many production service meshes and API gateways. Envoy Gateway brings Envoy’s capabilities to Kubernetes via the Gateway API, without a full service mesh.
Why we like it:
- First-class Gateway API conformance. If the Gateway API spec supports it, Envoy Gateway implements it.
- SIG-Network maintains the ingress2gateway tool for converting Ingress resources to Gateway API resources. The community ingress2eg tool (an unofficial extension of ingress2gateway) adds support for converting NGINX annotations to Envoy Gateway CRDs.
- Vendor-neutral and community-governed. The OSS version is fully capable without commercial licensing.
- Strong observability out of the box (Envoy’s stats, tracing, and access logging are best-in-class).
- Robust extensibility model without the injection risks of config templating.
The catch: This is not a drop-in replacement. You’re migrating to an entirely different resource model (Ingress → HTTPRoute). The conversion tools help, but this is a rewrite of your routing configuration, not a swap. For ISVs shipping into customer clusters, this means your Helm charts need to produce Gateway API resources instead of Ingress resources, and your customers must deploy a Gateway API implementation.
For ISVs: Best choice if you’re planning a clean break from the Ingress API and want to align with where Kubernetes networking is heading long-term. Consider shipping your Helm charts with support for both Ingress and Gateway API resources during a transition period, gated by a Helm value.
For most teams, Traefik or Envoy Gateway will be the right choice. If you want to understand the broader landscape, read on — otherwise, skip to Advice for ISVs Shipping with Replicated.
How We Tested Ingress NGINX Alternatives
We tested Ingress API and Gateway API implementations to find the best ingress-nginx alternatives for ISVs. Since most teams need to move quickly and can’t afford a full rewrite of their routing configuration, we focused on two primary criteria:
- Drop-in replacement support: Can you swap the controller without rewriting your Ingress manifests and annotations?
- Community support and project maturity: Is this backed by a sustainable organization? Does it have a clear roadmap? Will it be here in three years?
We also considered Gateway API readiness, impact on end customers’ environments, commercial upsell risk, and security architecture, which shaped the individual evaluations above.
Other Options We Surveyed
| Option | Best for | Key caveat |
|---|---|---|
| Chainguard EmeritOSS | Buying time — security patches and dependency updates for a maintained fork of ingress-nginx | Stopgap only. No new development, and the architectural vulnerabilities (config templating, injection surface) remain. Don’t build your 2026 strategy on this. |
| F5 NGINX Ingress Controller (OSS) | Teams deeply invested in NGINX behavior and config patterns | Not a drop-in swap. Requires translating annotations to nginx.org/* or adopting VirtualServer CRDs. Advanced features gated behind NGINX Plus. |
| HAProxy Ingress Controller | High-throughput workloads and TCP/UDP routing beyond HTTP/S | No drop-in compatibility layer for ingress-nginx annotations. Unified Gateway (Ingress + Gateway API in one) still in beta. |
| Contour | Teams already using Contour or wanting an Envoy-based CNCF project | Less community momentum than Envoy Gateway for new deployments. |
| Kong Ingress Controller | API-heavy applications that benefit from built-in rate limiting, auth, and plugins | Commercial model is more prominent than alternatives. |
| Istio Gateway | Clusters already running Istio | Overkill as an ingress dependency. Heavier lift than purpose-built alternatives even without the full mesh. |
.
Advice for ISVs Shipping with Replicated
If you’re shipping your application into customer-managed clusters using Replicated, here’s our specific guidance:
- Audit your annotation usage now. Run kubectl get ingress -A -o yaml | grep “nginx.ingress.kubernetes.io” across your test environments. Know exactly what you depend on.
- Don’t bundle ingress-nginx after March 2026. If your application Helm chart currently deploys ingress-nginx as a subchart, start planning the replacement. Shipping unmaintained software with known architectural vulnerabilities into customer clusters is a liability.
- Consider making the ingress controller configurable. Rather than hard-coding a dependency on a specific controller, structure your Helm charts so customers can bring their own. Use ingressClassName consistently, avoid controller-specific annotations where possible, and document what your application needs from its ingress layer.
- Bundle Traefik if you must ship a controller. Its NGINX Provider minimizes disruption, it’s lightweight, it supports both Ingress and Gateway API, and it’s easy to deploy as a subchart.
- Start testing Gateway API support in your charts. The Ingress API is feature-frozen. Gateway API is where active development is happening. Even if you don’t switch today, adding Gateway API resources behind a Helm value positions your application for the future.
The March 2026 deadline is real. Start planning now.
Have questions about migrating your application’s ingress configuration? Contact our team — we’ve helped dozens of vendors navigate infrastructure transitions like this.