7 min Reading Time

As of March 2026, Ingress-NGINX is officially end-of-life. No patches, no security updates, no bug fixes. The Kubernetes project has retired the world’s most widely used Ingress controller. Roughly half of all cloud-native environments are affected. Anyone who doesn’t migrate now is running internet-exposed workloads with an abandoned component.

TL;DR

• 🚨 Ingress-NGINX reached end-of-life in March 2026. No further security updates (Kubernetes project, November 11, 2025).
• 📊 Approximately 50% of all cloud-native environments use Ingress-NGINX (Kubernetes Steering Committee, January 29, 2026).
• ✅ Gateway API v1.4 is the official successor. Production-ready since October 2025 (CNCF).
• 🔄 Traefik, HAProxy, and F5 NGINX Ingress Controller are proven community alternatives.
• 🏢 KubeCon Europe 2026 in Amsterdam (March 23-26) makes migration a must-have topic for platform teams.

What Happened – and Why It’s Urgent Now

On November 11, 2025, the Kubernetes project published a blog post announcing the retirement of Ingress-NGINX. The controller, long the de facto standard for HTTP routing in Kubernetes clusters, will receive no further updates after March 2026. The GitHub repository has been set to read-only and moved to the kubernetes-retired organization.

What this means in practice: every new CVE in NGINX or in the controller logic will remain unpatched. For a component directly exposed to the internet and handling all inbound cluster traffic, this poses a serious security risk.

On January 29, 2026, the Kubernetes Steering Committee and Security Response Committee reinforced the message. In an official statement, they quantified adoption: roughly 50% of all cloud-native environments rely on Ingress-NGINX (source: Datadog Research). Their recommendation is clear: evaluate Gateway API as the official successor, plan your migration – and don’t wait.

Gateway API: The Official Successor

The Kubernetes community has been preparing this transition for years. Gateway API isn’t just another Ingress controller – it’s a fundamentally different approach. Instead of a single Ingress resource cluttered with annotations, Gateway API introduces separate resources for infrastructure (GatewayClass, Gateway) and routing (HTTPRoute, GRPCRoute, TCPRoute).

Since October 2025, Gateway API v1.4.0 has been in General Availability status. GatewayClass, Gateway, and HTTPRoute are stable and production-ready. This is no longer beta software. Companies like Google, Red Hat, and VMware already use Gateway API in their managed Kubernetes offerings.

The key advantage: role-based configuration. Cluster administrators define the gateway infrastructure, while developer teams independently configure their routes. In Ingress-NGINX, everything was crammed into a single resource with hundreds of annotations – understood by only a few team members.

“Gateway API models Kubernetes networking in an expressive, extensible, and role-oriented way.”
– Kubernetes Documentation, Gateway API Concepts (paraphrased)

Top Three Alternatives Compared

Gateway API is the strategically sound choice. But not every team can switch immediately. Depending on your cluster setup, annotations, and integrations, migration paths vary.

Traefik was among the first controllers to implement full Gateway API v1.4 support. If you already use Traefik as a reverse proxy, you can migrate with minimal effort. Traefik Labs provides a detailed migration guide with step-by-step mappings from Ingress annotations to Gateway API resources.

F5 NGINX Ingress Controller is the commercially maintained fork. If you want to stay with NGINX without relying on community support, this option requires the least reconfiguration. Configuration remains nearly identical – only the namespace and Helm charts change. The downside: vendor lock-in and licensing costs.

HAProxy Ingress Controller is the most stable 1:1 replacement for teams seeking a lean, battle-tested controller. HAProxy Technologies actively maintains it and has Gateway API support on its roadmap.

Planning Your Migration: 5 Steps for Platform Teams

Migrating away from Ingress-NGINX isn’t a weekend project. Platform teams should proceed methodically.

Step 1: Take inventory. Catalog all Ingress resources in your cluster. Which annotations are in use? What custom configurations live in ConfigMaps? Tools like Fairwinds Insights can help estimate migration scope.

Step 2: Choose your target controller. Use Gateway API for greenfield projects and long-term strategy. Opt for Traefik or F5 NGINX if you need to migrate quickly while preserving existing Ingress manifests.

Step 3: Run in parallel. Install the new controller alongside Ingress-NGINX. Gradually shift traffic – route by route. Don’t flip the switch all at once.

Step 4: Update monitoring. Ingress-NGINX-specific Prometheus metrics (e.g., `nginx_ingress_controller_*`) won’t exist in the new controller. Dashboards and alerts must be rebuilt using the new metric names.

Step 5: Uninstall Ingress-NGINX. Only after all routes are migrated and the new controller runs stably. Never keep both running indefinitely – that doubles your attack surface.

Common Migration Pitfalls

The biggest challenges in migrating from Ingress-NGINX often lie not in the controller itself, but in the surrounding ecosystem.

Annotations without equivalents. Ingress-NGINX supports over 100 annotations – from rate limiting and CORS to custom headers. Not all have direct counterparts in Gateway API. Teams must audit which annotations are actually used and determine how to replicate that functionality in the new controller.

cert-manager integration. Many teams use cert-manager with Ingress-NGINX for automated TLS certificates. cert-manager has native Gateway API support since version 1.15. Migration is usually straightforward, but Gateway resources require different labels than Ingress resources.

External-DNS. If you use External-DNS for automatic DNS entries, verify that your version recognizes Gateway API resources. Older External-DNS versions only work with Ingress objects.

Custom error pages and snippets. Ingress-NGINX allows custom NGINX snippets via annotations – a powerful but risky feature. Gateway API intentionally omits equivalent functionality. Teams using snippets must move that logic into the controller itself or into middleware.

Why the Kubernetes Project Retired Ingress-NGINX

Retiring Ingress-NGINX wasn’t a technical failure – it was a strategic cleanup. Launched in 2016 as a reference implementation, it grew into the de facto standard. But that very success became a problem: over 100 annotations, no clear role separation, and a codebase increasingly difficult to maintain with each NGINX update.

Security incidents accelerated the decision. In October 2025, the Kubernetes Security Response Committee published a report detailing multiple critical vulnerabilities in the Ingress-NGINX admission webhook. Combined with high adoption, complex code, and dwindling maintainer capacity, retirement became inevitable.

For the Kubernetes ecosystem, this is a healthy step forward. Gateway API doesn’t just replace Ingress-NGINX – it replaces the entire Ingress concept. Instead of vendor-specific annotations, we now have standardized resources any controller can implement. This reduces lock-in and makes Kubernetes networking more portable.

What DACH Companies Should Prioritize Now

Regulated industries in Germany, Austria, and Switzerland face heightened pressure. NIS2-compliant organizations must demonstrate that their IT infrastructure is actively maintained. Running an Ingress controller without security support constitutes a documented compliance risk.

Financial services and healthcare providers should prioritize migration first. Proof of actively maintained components is part of the supply chain documentation required by NIS2. Operating an end-of-life component at your internet perimeter during an audit creates serious justification challenges.

Mid-sized companies with small platform teams benefit especially from Traefik or F5 NGINX as interim solutions. They can then migrate to Gateway API in a second phase once capacity and expertise are built up.

KubeCon Europe 2026: Migration Becomes Mandatory

From March 23-26, 2026, the KubeCon Europe returns to Amsterdam. Ingress-NGINX migration dominates the platform engineering track agenda. For teams that haven’t migrated yet, the conference offers hands-on workshops and real-world case studies from organizations that have already completed the transition.

Not attending in person? Talks are typically published on YouTube within four weeks. But waiting isn’t a strategy. Every day without security updates is another day of open risk.

Conclusion

Ingress-NGINX was the standard for years. That era is over. Its retirement isn’t a surprise – it’s the result of a deliberate Kubernetes community decision in favor of Gateway API. Anyone who fails to act now is operating a security-critical component without support.

The pragmatic path: adopt Gateway API for new projects and as your strategic goal. Use Traefik or F5 NGINX as a bridge solution for teams needing rapid response. Run both controllers in parallel, migrate incrementally, and fully remove Ingress-NGINX only when stable.

The question isn’t if – it’s how fast.

Frequently Asked Questions

What happens if I keep using Ingress-NGINX?

It will continue to function technically, but you’ll receive no more security updates. Every new vulnerability in NGINX or the controller code will remain unpatched. For internet-facing workloads, this represents an escalating risk.

How long does migration to Gateway API take?

It depends on the number of Ingress resources and annotations used. Small clusters with 10-20 routes can typically migrate in one to two weeks. Large setups with custom snippets and complex routing rules may require four to eight weeks.

Can I run Gateway API and Ingress-NGINX side by side?

Yes – in fact, it’s recommended. Install the new controller in parallel, migrate route by route, and remove Ingress-NGINX only after all routes are stable.

Is Traefik better than Gateway API?

Traefik is an implementation; Gateway API is a specification. Traefik fully supports Gateway API v1.4. You can use Traefik as your controller while adopting Gateway API resources – they’re complementary, not mutually exclusive.

What does the F5 NGINX Ingress Controller cost?

F5 offers the NGINX Ingress Controller in both a free open-source version and a commercial Plus edition. The Plus version requires an NGINX Plus license, priced based on the number of instances.

Further Reading

• Kubernetes Cluster Governance in Mid-Market Companies – Why Control Matters More Than Scale (cloudmagazin)
• TLS Certificates in 2026 – Why 200-Day Validity Ends Manual Management (cloudmagazin)
• Cloud-Native Identity – OAuth 2.1, Passkeys and the Future of Authentication (cloudmagazin)

More from the MBF Media Network

• SBOM Practical Check – How Your Company Implements the Software Bill of Materials (SecurityToday)
• Cloud Repatriation 2026 – Why CIOs Are Bringing Workloads Back On-Premises (Digital Chiefs)

Header Image Source: Brett Sayles / Pexels