Ingress NGINX is Out and There’s Only One Realistic Alternative

Traefik v3.7 brings 80+ NGINX Ingress annotations, snippet support, and a zero-downtime migration path.

Last July, when we first introduced Ingress NGINX native support to Traefik, we knew something was happening, but we didn't yet know how soon the situation would escalate. Then came November: the Kubernetes SIG Network and Security Response Committee officially announced that the Ingress NGINX Controller would be retired in March 2026. No new releases. No bug fixes. No security patches.

As of this month, that deadline has arrived. If you're running Ingress NGINX in production—and millions of clusters still are—you're now running unmaintained software with known architectural vulnerabilities.

Over the past months, we've been on a singular mission: make the migration from Ingress NGINX a non-event. Not a multi-quarter project. Not a forced rearchitecture. A non-event. Today, I want to share where we've arrived, what's new, and why we believe Traefik is the only path that doesn't ask you to choose between safety and disruption.

And the path we've taken has been validated by the industry. This morning, we're proud to announce that IBM Cloud, Nutanix, OVHcloud, SUSE, TIBCO, and others have each independently chosen Traefik as their strategic ingress controller and Gateway API solution. These aren't experiments or evaluations. These are production commitments from organizations that evaluated every option on the table and concluded that Traefik's approach, native Ingress NGINX compatibility combined with full Gateway API support, is the right foundation for their Kubernetes networking stack going forward.

The Alternatives All Have the Same Problem

Since the retirement announcement, the ecosystem has responded along two lines. Neither solves the fundamental issue.

The First Approach: Migrate to a Different Configuration Format

Every major proxy vendor (e.g., Kong, HAProxy, NGINX F5, cloud-native providers) has published migration guides. We've read them all. They all share the same fundamental limitation: they require you to rewrite your configurations immediately.

Either you convert your NGINX annotations to a completely different set of vendor-specific annotations, or you jump straight to Gateway API resources. In both cases, every annotation, every routing rule, every customization must be manually converted to a different syntax, a different mental model, a different set of abstractions to land you on a new controller UX that you do not master yet. Under deadline pressure, this is a recipe for outages.

The Second Approach: Fork Ingress NGINX and Keep Running It

Following the retirement announcement, a maintenance fork emerged to keep the project alive by providing security patches. It's a tempting narrative; just switch the image and stay safe. But as we explained in detail in our analysis, a fork doesn't fix the fundamental architectural flaws. The configuration injection surface that enabled #IngressNightmare isn't a bug to patch. It's a consequence of how NGINX-based controllers work—template rendering, C/C++ memory safety risks, etc.

A fork inherits all of these structural vulnerabilities. And it anchors you to a legacy technology with no path forward. Finally, if the original maintainers gave up, how could a third-party vendor make this project safe to use?

Meanwhile, InGate, the proposed from-scratch successor, has also been announced as end-of-life in March as well. The official Kubernetes path forward for ingress is Gateway API, but Do It Yourself.

Traefik’s Approach: The Only Drop-In Replacement

We took a fundamentally different approach. Traefik's NGINX Ingress Provider reads your existing Ingress resources and their nginx.ingress.kubernetes.io annotations natively. No conversion scripts. No YAML rewriting. No dual-maintenance period where you're running two sets of configurations side by side.

This isn't a compatibility shim or a best-effort translation layer. It's a full provider that understands the Ingress NGINX annotation contract and translates it into Traefik's internal object model securely, without the configuration-injection vulnerabilities that plague template-based approaches.

This makes Traefik the only drop-in replacement for Ingress NGINX in the industry. And critically, Traefik is also the only solution that supports both Ingress NGINX annotations and Gateway API on the same cluster, on the same instance, at the same time. This is what makes a truly seamless migration possible, and this is exactly why IBM Cloud, Nutanix, OVHcloud, SUSE, TIBCO, and others chose Traefik as their path forward.

What's New: A Data-Driven Expansion of Annotation Support

From the beginning, we took a data-driven approach to deciding which annotations to support and in what order. Our open-source ingress-nginx-migration tool doesn't just analyze your cluster, when users opt in, it shares anonymized, aggregated statistics with us. No resource names, no namespaces, no configurations. Just annotation counts and usage patterns.

The result: we now have an excellent overview of real-world annotation usage across hundreds of diverse deployments, from small startups running a handful of Ingresses to large enterprises with thousands. This data has directly shaped our implementation priorities, ensuring that every annotation we add addresses actual production needs, not hypothetical edge cases.

Introducing Traefik v3.7: 80+ NGINX Ingress Annotations, 90% of Real-World Usage, Available Now

Today we are releasing Traefik v3.7 early access, and it's the biggest leap forward yet for Ingress NGINX migration. This release brings support for over 80 NGINX Ingress annotations natively, covering more than 90% of real-world usage patterns we've observed across hundreds of production clusters. Authentication, TLS, session affinity, CORS, routing, proxy settings, rate limiting, canary deployments, snippets, and more: they all work out of the box, with your existing Ingress manifests, unchanged.

This is the release that turns the Ingress NGINX sunset from a migration project into a configuration change.

Snippets: A Pragmatic Solution to the Long Tail

One of the most interesting findings from our migration tool data was the prevalence of configuration-snippet and server-snippet annotations. These are the escape hatches of the Ingress NGINX world (i.e., raw NGINX configuration directives injected directly into the generated config). They're also the primary vector behind the IngressNightmare vulnerabilities, and the reason a naive "just support all annotations" approach is a security non-starter.

But we can't ignore them either. Our data shows that snippets are heavily used in production, and a significant portion of "unsupported" Ingresses rely on them.

So we built something new: partial snippet support through a basic interpreter. Rather than blindly injecting raw NGINX configuration, which would recreate the exact security vulnerabilities we're trying to avoid, Traefik now parses snippet content and interprets a curated set of the most commonly used NGINX directives.

This covers the most common snippet use cases without enabling arbitrary configuration injection. It's a pragmatic middle ground: broad enough to unblock real migrations but strict enough to maintain Traefik's security-by-design guarantees.

Variable Interpolation

Alongside snippet support, Traefik now supports variable interpolation, initially focused on the headers manipulation use case. If your snippets use NGINX variables to set or modify request and response headers—referencing client IPs, URI components, or upstream information—Traefik maps them to their equivalent values in its own routing context.

This was another priority directly informed by our migration data. Header manipulation through snippets with variable interpolation is one of the most common patterns we observed, and without this support, even a well-parsed snippet would produce incorrect behavior. The architecture is designed to expand variable coverage to additional use cases based on community feedback.

Annotation Support: The Full Picture

Here's a snapshot of the 80+ NGINX Ingress annotations now supported by Traefik's NGINXIngress Provider, as available in the v3.7 early access.

For the full technical reference with behavioral notes and limitations, see the NGINX Ingress Provider documentation.

Many of these annotations were implemented by community contributors, and that momentum continues to grow. If you need support for annotations not listed here, or want to help expand coverage further, head to traefik/traefik#12631. Annotations are categorized by complexity (Basic, Medium, Complex), making it easy to find a contribution that matches your experience level.

More than half of Traefik's merged pull requests have historically come from external contributors. The Ingress NGINX Provider is proving to be no exception.

The Migration: Three Phases, Zero Downtime, Zero Risk

We designed the migration from Ingress NGINX to be a simple, three-phase process. All three phases uphold our core principles: zero downtime, progressive transition, and a smooth experience that lets you move at your own pace.

Phase 1: Assess Your Situation

Run the ingress-nginx-migration tool against your cluster. In minutes, you'll get a clear picture of your annotation usage and compatibility status: which Ingresses will migrate seamlessly, and which ones need attention. No manual audits are required.

Phase 2: Ingress NGINX Decommissioning

Deploy Traefik alongside your existing NGINX controller. Both will serve the same Ingress resources simultaneously. Progressively shift traffic to Traefik, one Ingress at a time, validating behavior with each step. Once you're confident, remove Ingress NGINX. There is no big-bang cutover, no downtime, and your production traffic remains secure while you eliminate the unmaintained software from your stack.

Phase 3: Progressive Transition to Gateway API

With Traefik handling your existing Ingress resources and their NGINX annotations, you're no longer under a deadline. When you're ready (not when a crisis forces you), you can begin converting individual Ingress resources to Gateway API. Traefik supports both simultaneously, allowing you to migrate one route at a time, validate behavior, and roll back if needed. This is a seamless, progressive modernization with zero downtime.

This three-phase approach is unique to Traefik. No other solution provides both a drop-in replacement for Ingress NGINX and a production-grade Gateway API implementation that runs side by side, enabling a fully progressive migration from legacy to modern at your own pace.

The retirement of Ingress NGINX doesn't have to be a crisis. We built a migration path for you because we believe no one should be forced to rearchitect under pressure. The Kubernetes ecosystem deserves better than that. 

None of this would have been possible without the incredible contributions from the community. Developers from around the world have submitted pull requests adding new annotations, reporting edge cases, improving documentation, and testing the provider against their own production configurations. This effort is as much yours as it is ours, and we're deeply grateful for it.

If you haven't already, we invite you to try the Traefik v3.7 early access release against your own cluster. Run the migration tool, deploy Traefik alongside NGINX, and see for yourself how many of your Ingresses just work. Your feedback on this release will directly shape the final v3.7 GA.

The deadline is here. But for Traefik users, it's just another Tuesday.

Resources:

• Migration tool: github.com/traefik/ingress-nginx-migration
• Migration guide: doc.traefik.io/traefik/migrate/nginx-to-traefik
• Early Access: Traefik v3.7 Early Access: v3.7.0-ea.2
• Contribute annotations: traefik/traefik#12631
• Full annotation reference: doc.traefik.io/.../ingress-nginx
• Migration website: ingressnginxmigration.org
• Why a fork won't save you: The Illusion of Safety