Ingress-NGINX is discontinued: The path to Gateway API

24 June 2026

7 min read

On 24 March 2026 the Kubernetes project archived the ingress-nginx repository. Since then no bug fixes or security patches have been issued for the controller that terminates web traffic in most clusters. Anyone still running it is operating their most critical network component without maintenance.

Key Takeaways

End-of-life is final: Since 24 March 2026 ingress-nginx has been archived-no new features, no bug fixes, no CVE patches. The underlying Kubernetes Ingress API remains, but the popular community controller does not.
The Gateway API is the designated successor: Version 1.5.1 is stable, multiple conformant controllers are available, and the ingress2gateway 1.0 tool automatically converts more than 30 annotations.
The effort lies in edge cases: The standard path is mechanical, yet Auth snippets, session affinity and canary rules must be rebuilt by hand.

Why the clock has run out

The announcement arrived in November 2025 from the Kubernetes SIG Network and the Security Response Committee; a follow-up statement in January 2026 underlined the gravity. By March 2026 the best-effort maintenance ended and the GitHub repository was archived on 24 March. There is no long grace period to sit it out-the support is over.

The real issue is not missing functionality but security exposure. New vulnerabilities continue to surface; the NGINX Rift heap-overflow disclosed in May 2026 affected archived builds as well. No patches will ever arrive. Running end-of-life software directly in the Layer-7 data path triggers automatic findings in audits under SOC 2, PCI-DSS or ISO 27001. Anyone needing compliance evidence now has an open red flag.

One clarification is vital because it is often muddled: the Kubernetes Ingress API itself is not disappearing. It remains generally available but frozen. Active development has fully migrated to the Gateway API. The concrete controller ingress-nginx is affected, not the concept of Ingress per se.

What is the Gateway API? The Gateway API is a Kubernetes standard for Layer-7 routing that replaces the older Ingress API. It cleanly separates roles between infrastructure and application teams, describes routes in far more expressive terms and is designed from the ground up for multi-tenancy inside the same cluster. Since 2026 it has been the official path for new network code.

Security patches for ingress-nginx have been issued since the end-of-life date on 24 March 2026. Every new L7-path vulnerability remains permanently unpatched.

Source: Kubernetes SIG Network, Security Response Committee

Three Paths, One Main Route

Every team still running on ingress-nginx faces three choices. The differences lie less in the technology itself than in the timeline and how much technical debt you’re willing to carry forward.

The first path is migrating to the Gateway API. This is the direction the ecosystem is heading, and for most clusters it’s the cleanest cut. The second path is switching to a different Ingress Controller-Traefik, HAProxy, Envoy Gateway, or the commercial F5-NGINX variant. This keeps the familiar Ingress API alive but merely postpones the strategic decision. The third path is commercial security support for the archived version, offered by third-party vendors. That buys time for an orderly migration but doesn’t solve the underlying problem.

For new platforms and anyone already planning modernization, the choice falls on the Gateway API. The comparison below explains why-and where the honest trade-offs lie.

Why Gateway API wins

Official development track-all new features land here
Clean separation of concerns between infrastructure and application
More expressive routes without annotation sprawl
Portable across conformant controllers

Where it still stumbles

Custom annotations don’t map 1:1
The team must learn a second resource model
Observability and dashboards need new wiring
The controller maturity varies by feature

The Migration in Five Steps

The good news first: for the standard case, the move is now mechanical. Since 20 March 2026, ingress2gateway has reached version 1.0-a stable tool from the SIG Network that translates existing Ingress definitions, including more than 30 common annotations, into Gateway and HTTPRoute objects. Follow the sequence below and you’ll keep downtime at zero.

Zero-downtime migration path

Step 1

Inventory your estate. List every Ingress object and its annotations. The number of routes doesn’t drive the effort; the list of edge cases does.

Step 2

Install the CRDs. Roll out the Gateway-API resources from the standard channel, version 1.5.1. Traffic remains untouched; you’re only laying down the new vocabulary.

Step 3

Pick and deploy a controller. Run a conformant controller such as Envoy Gateway in parallel with your existing ingress-nginx. Two data paths side-by-side, still no cut-over.

Step 4

Convert with ingress2gateway. Feed the tool your Ingress YAML; it emits Gateway and HTTPRoute objects. Inspect the output-don’t apply blindly, especially when you’ve added custom annotations.

Step 5

Shift traffic incrementally. Move route by route or via weighted DNS to the new path, watch metrics, then decommission the old controller. Migration is complete only when nothing still points to ingress-nginx.

Where the details get sticky

The five steps sound smooth, and they are-for a platform that has kept its Ingress rules clean and generic. Friction appears where teams have spent years collecting annotations that are specific to ingress-nginx. No tool translates those fully.

The most common tripwires are easy to spot in advance. Auth snippets and external authentication must be rebuilt around the Gateway API’s filter model. Sticky sessions and session affinity are modeled differently than the old cookie annotations. Canary deployments that once ran via annotation now live in weighted HTTPRoute rules. Anything tied to custom snippets or embedded NGINX config simply has no direct counterpart in the new world-this is intentional, not a shortcoming of the Gateway API.

Yet there’s upside that only becomes visible once you’re live. The Gateway API’s clear separation of roles lets the platform team own the gateway while application teams create their own routes without touching shared infrastructure. If you’re already migrating, you can use the exercise to finally carve out those responsibilities cleanly. What feels like a forced compliance task can turn into platform hygiene you’d never have prioritised otherwise.

Frequently Asked Questions

Do I need to migrate immediately, or will ingress-nginx just keep running?

Technically, the last version continues to run and won’t vanish from the cluster. However, it will no longer receive security updates. Any new vulnerabilities will remain unpatched, and in compliance audits, end-of-life software in the data path counts as a finding. The right time to migrate is therefore more like yesterday than later.

Does the Kubernetes Ingress API itself remain available?

Yes. The Ingress API remains generally available, though it is now frozen and will not gain new features. Only the community controller ingress-nginx has been deprecated. If you want to stay with the Ingress API, you can switch to another controller such as Traefik or HAProxy.

What exactly does the ingress2gateway tool do?

It reads existing Ingress definitions and generates corresponding Gateway and HTTPRoute objects. Version 1.0 supports more than 30 common ingress-nginx annotations. For standard cases the conversion is mechanical, but you should still review the generated output before applying it.

Which controllers are alternatives to the Gateway API?

If you don’t want to switch to the new model, you can replace ingress-nginx with Traefik, HAProxy, Envoy Gateway, or the commercial F5 NGINX variant. These keep the familiar Ingress API, but the fundamental decision is merely postponed rather than resolved.

How can I keep downtime at zero when switching?

Run the new controller in parallel alongside ingress-nginx, shift traffic route-by-route or via weighted DNS, and monitor the process. Only decommission ingress-nginx once no traffic remains on the old path.