120 Days Until Ingress NGINX Dies: Traefik is the Only True Drop-in Replacement

The Kubernetes community was shaken on November 12, 2025, when maintainers of the Ingress NGINX project announced: Ingress NGINX Controller will be retired in March 2026. After March 2026, there will be no releases, no bug fixes, and critically, no security updates.

Organizations now have just 4 months to migrate away from one of the most widely deployed ingress controllers in the ecosystem. This isn't theoretical—if you're running production workloads on Ingress NGINX after March 2026, you're running unmaintained software with potential security vulnerabilities. Historically, there have been critical vulnerabilities discovered in this project, including the #IngressNightmare vulnerabilities that demonstrated how attackers could compromise entire clusters through malicious configuration injection.

The timeline is brutal and many organizations are already behind schedule before they've started.

Why Traefik is Your Only Realistic Option

Earlier this year, we published a deep-dive into the #IngressNightmare situation and how to transition from Ingress NGINX to Traefik. In short, we added an Ingress NGINX compatibility layer to Traefik, introducing native support for many custom annotations and creating the only drop-in replacement for Ingress NGINX in the industry.

Here's the reality: every other ingress controller requires you to rewrite your configurations. F5 NGINX Ingress, HAProxy Ingress, cloud provider solutions—e.g., AKS, AWS, etc.—they all provide migration guides, annotation mappings, or promote a Gateway API transition, not migration compatibility. You'll need to manually convert every custom annotation, test every configuration, and essentially rebuild your ingress layer from scratch.

Traefik's NGINX Provider works differently. Most used nginx.ingress.kubernetes.io annotations are handled natively by Traefik. Your Ingress objects work unchanged. This is a huge differentiator compared to other solutions.

But compatibility alone isn't enough in this crisis. Traefik offers three critical advantages that make it the only realistic choice:

Security by Design: The #IngressNightmare vulnerabilities revealed fundamental architectural flaws in NGINX-based solutions. Traefik's architectural choices—Go over C/C++, static linking, structured parsing over templating—prevent the memory safety and configuration injection attacks that plague NGINX controllers.

Broad Ecosystem Adoption: With 3.4+ billion downloads, 58,000+ GitHub stars, and 900+ contributors, Traefik isn't experimental—it's battle-tested across startups and enterprises. Unlike solutions adapted for Kubernetes, Traefik was designed specifically for dynamic, cloud-native environments.

Gateway API Leadership: As a key contributor to Gateway API specification with full v1.4 support in Traefik v3.6, you're positioning for the future of Kubernetes networking, not just solving today's crisis. While others treat Gateway API as experimental, Traefik has made it core.

When you're facing a 120-day deadline with no margin for error, Traefik emerges as the obvious choice—seamlessly compatible with your existing deployments while positioning you for the future of cloud-native networking.

Stop the Bleeding First, Then Modernize

The retirement of Ingress NGINX is an urgent, time-sensitive problem demanding a structured migration strategy. It can be tempting to directly think of Gateway API as the obvious solution. Indeed, this new Kubernetes specification handles much more than the Ingress specification, and we are not only a big fan at Traefik Labs, but we are leading this standard as the future of Kubernetes networking.

However, Gateway API requires a complete migration of all your ingress resources to a new set of resources: Gateway, GatewayClass, HTTPRoute, TLSRoute, etc. And this is clearly not something you can (or should) do in a short period of time.

Trying to simultaneously solve the immediate crisis of a looming deprecation deadline and the long-term goal of ingress modernization is a mistake. The prudent, risk-averse approach separates these concerns into distinct, manageable phases.

Phase 1: Ingress NGINX Decommissioning. Get off Ingress NGINX before security updates stop. Migrate to Traefik with the NGINX Provider for drop-in compatibility. Maintain existing workflows and ensure production stability through the deadline.

Phase 2: Gateway API Modernization. Plan Gateway API adoption on your timeline, not under deadline pressure. Assess readiness during normal sprint cycles, test thoroughly, implement when business conditions are optimal.

Your immediate problem is Ingress NGINX retirement, not Ingress API modernization. Solve one crisis at a time.

How to Decommission Ingress NGINX, in a Nutshell

First, let’s dig deeper into the basics with a nominal use case. Let’s say:

You operate a Kubernetes cluster
There is a running ingress-nginx controller instance
A Kubernetes IngressClass named nginx with the controller value set to k8s.io/ingress-nginx and Kubernetes Ingresses have an ingressClassName set to nginx
And a Kubernetes service of type LoadBalancer exists exposing the ingress-nginx controller instance on port 80 and 443

You have this ingress with TLS and basic authentication deployed:

kind: Ingress
apiVersion: networking.k8s.io/v1
metadata:
  name: ingress-with-basicauth
  namespace: default
  annotations:
    # Configure basic authentication for the Ingress
    nginx.ingress.kubernetes.io/auth-type: "basic"
    nginx.ingress.kubernetes.io/auth-secret-type: "auth-file"
    nginx.ingress.kubernetes.io/auth-secret: "default/basic-auth"
    nginx.ingress.kubernetes.io/auth-realm: "Authentication Required"
    # SSL Redirect
    nginx.ingress.kubernetes.io/ssl-redirect: "true"

spec:
  ingressClassName: nginx
  rules:
    - host: myappdomain
      http:
        paths:
          - path: /
            pathType: Prefix
            backend:
              service:
                name: whoami
                port:
                  number: 80
  tls:
    - hosts:
        - myappdomain
      secretName: external-certs

---
kind: Secret
apiVersion: v1
metadata:
  name: basic-auth
  namespace: default
type: Opaque
data:
  # user:password
  auth: dXNlcjp7U0hBfVc2cGg1TW01UHo4R2dpVUxiUGd6RzM3bWo5Zz0=

Deploy Traefik alongside your existing Ingress NGINX setup. Traefik is installed in `ClusterIP` mode to be able to test the routing.

$ helm repo add traefik https://traefik.github.io/charts
$ helm repo update
$ helm upgrade --install traefik traefik/traefik --namespace traefik \
  --create-namespace \
  --set="image.tag=v3.6.2" \
  --set="logs.general.level=DEBUG" \
  --set="service.type=ClusterIP" \
  --set="additionalArguments={--providers.kubernetesIngressNGINX}"

Check that the routing is working with a port-forward

$ kubectl port-forward -n traefik services/traefik 9000:80 9443:443
Forwarding from 127.0.0.1:9000 -> 8000
Forwarding from [::1]:9000 -> 8000
Forwarding from 127.0.0.1:9443 -> 8443
Forwarding from [::1]:9443 -> 8443

$ curl https://myappdomain:9443
401 Unauthorized

$ curl -u user:password https://myappdomain:9443
Hostname: whoami-b85fc56b4-5pvcv
...

Depending on how your Ingress NGINX controller has been deployed, you might also need to recreate the nginx IngressClass, if it’s removed when Nginx is uninstalled.

Then, you can remove the Ingress NGINX deployment, update the Traefik deployment to change the Service type to LoadBalancer, update the DNS record, and check that Traefik serves your untouched ingress resources 🙂

$ helm upgrade --install traefik traefik/traefik --namespace traefik \
  --create-namespace \
  --set="image.tag=v3.6.2" \
  --set="logs.general.level=DEBUG" \
  --set="service.type=LoadBalancer" \
  --set="additionalArguments={--providers.kubernetesIngressNGINX}"

$ curl -u user:password https://myappdomain              
Hostname: whoami-b85fc56b4-q6427
...

It’s as simple as that. nginx.ingress.kubernetes.io annotations are handled natively by Traefik and your ingresses stay unchanged.

For large Kubernetes deployments with numerous workloads and Ingress resources, we recommend a progressive migration. Deploy new clusters with Traefik, and then gradually transition your existing workloads and associated Ingress configurations to these new clusters. This approach allows for thorough validation, provides an easy rollback mechanism if necessary, and ensures the entire migration process remains manageable.

The Traefik Labs team possesses extensive experience with various Kubernetes deployments and is well-equipped to provide commercial assistance, helping you plan and execute your migration efficiently and seamlessly. Feel free to reach out to us if you need help.

Time to Execute

The retirement of Ingress NGINX is serious, but it's not the Kubernetes apocalypse. With 120 days remaining and Traefik's proven compatibility layer, you have enough time to migrate safely if you act now.

Don't let deadline pressure force you into premature Gateway API adoption or manual configuration rewrites. Traefik's NGINX Provider offers the most realistic path forward with immediate compatibility, proven track record, and clear upgrade path to Gateway API when you're ready.

Our current implementation focuses on supporting the most commonly used Ingress NGINX custom annotations, covering 80% of real-world usage patterns. If you need additional annotation support, we can implement it. Feel free to open GitHub issues in Traefik's repository to tell us your needs. Better yet, contribute directly—adding new annotation support is straightforward and helps the entire community.

Our goal is simple: make this crisis a non-event. Every organization should be able to migrate off Ingress NGINX safely and quickly, without disrupting their operations or forcing architectural decisions under pressure.