Ingress NGINX is retired: how to check your clusters and migrate

The community Ingress NGINX controller is retired. Its final releases, controller v1.15.1, v1.14.5 and v1.13.9, shipped on March 19, 2026, and the kubernetes/ingress-nginx repository is now archived and read-only. Existing installations keep working and the images and Helm charts remain downloadable, but no bug fixes or security patches will be released for vulnerabilities found from now on.

If you still run it, Kubernetes SIG Network and the Security Response Committee recommend moving to a Gateway API implementation or to another maintained Ingress controller. Below: how to find the controller in your clusters, which replacement paths exist and where translations tend to break, as of October 2026.

What was retired, and what was not

The retirement covers the ingress-nginx controller maintained by the Kubernetes project, along with InGate, the planned successor that never reached maturity. It does not cover:

• The Ingress API. The Kubernetes documentation describes Ingress as frozen but generally available, and the project has no plans to remove it. New networking features go into Gateway API, which the project now recommends instead.
• F5's NGINX Ingress Controller. It is a separate product. Both use NGINX as the data plane but are otherwise unrelated, as the Kubernetes blog points out.

Retirement timeline

• November 11, 2025: SIG Network and the Security Response Committee announce the retirement, with best-effort maintenance until March 2026. The post cites years of having only one or two maintainers and features such as "snippets" annotations that had come to be seen as serious security flaws.
• January 29, 2026: the Steering and Security Response Committees publish a joint statement saying about half of cloud native environments rely on the controller, citing Datadog research, and that staying on it after retirement leaves users vulnerable to attack.
• March 19, 2026: final controller releases and Helm charts 4.15.1, 4.14.5 and 4.13.9.
• March 20, 2026: SIG Network releases Ingress2Gateway 1.0, a migration assistant.
• March 24, 2026: the GitHub repository is archived and becomes read-only.

The last release, v1.15.1, lists Kubernetes 1.31 to 1.35 as its tested versions. No release was tested against Kubernetes 1.36 or 1.37, so any cluster upgrade is one more reason to plan the move.

How to check whether you use ingress-nginx

The Kubernetes project suggests running this command with cluster administrator permissions:

kubectl get pods --all-namespaces --selector app.kubernetes.io/name=ingress-nginx

That label check finds standard Helm and manifest installs. Also review:

• IngressClass objects whose controller is k8s.io/ingress-nginx, the name the community controller registers;
• Ingress objects carrying nginx.ingress.kubernetes.io/ annotations, which were written for this controller;
• platform add-ons that bundle it. On AKS, the application routing add-on's managed NGINX is affected, and Microsoft supports it with critical security patches only through November 2026.

Replacement options

Gateway API

Gateway API is the project's recommended successor. It splits configuration into GatewayClass, Gateway and route resources such as HTTPRoute, so a platform team can own the shared entry point while application teams manage their own routes without extra permissions. Header-based matching, redirects, rewrites and weighted traffic splitting are part of the API rather than controller-specific annotations. The current release line is v1.6, first published in June 2026, and the project keeps a list of implementations.

Another Ingress controller

If you need to keep Ingress objects, the Kubernetes documentation maintains a list of Ingress controllers. The Steering Committee statement notes that none of the alternatives is a direct drop-in replacement: annotations, defaults and global options differ, so the testing steps below still apply.

Managed platform paths

Cloud providers have added their own routes. On AKS, managed Gateway API and the application routing add-on's Istio-based Gateway API implementation became generally available with release v20260428 on April 28, 2026, and Microsoft names the latter as the migration path for app routing NGINX users. The original Kubernetes announcement also notes that additional options may be available from vendors you already work with.

Translating configuration with Ingress2Gateway

Ingress2Gateway 1.0 reads Ingress manifests, or the live cluster, and writes Gateway API resources. Version 1.0 supports more than 30 common ingress-nginx annotations, up from three, including backend TLS, regex matching and path rewrites, and each is covered by integration tests against real controllers. It prints warnings for anything it cannot translate exactly. The newest release as of October 2026 is v1.2.0, published in July.

The 1.0 announcement gives two install options: go install github.com/kubernetes-sigs/ingress2gateway with a version tag (it pinned @v1.0.0; @v1.2.0 is the current release), or brew install ingress2gateway. Typical runs look like this:

• ingress2gateway print --input-file my-manifest.yaml --providers=ingress-nginx > gwapi.yaml
• ingress2gateway print --namespace my-api --providers=ingress-nginx > gwapi.yaml
• ingress2gateway print --providers=ingress-nginx --all-namespaces > gwapi.yaml

Adding --emitter with agentgateway, envoy-gateway or kgateway produces implementation-specific extensions. Treat the output as a draft: the project calls the tool a migration assistant, not a one-shot replacement, and says reviewing the output and warnings is the most critical step. Snippet annotations such as configuration-snippet contain raw NGINX directives and need a manual decision.

Five ingress-nginx behaviors that break in translation

A Kubernetes blog post from February 2026 lists defaults that a literal translation will not preserve, which can turn working routes into 404 errors after cutover:

1. Regex paths are prefix matches and case-insensitive. A pattern meant to match exactly three uppercase letters also matches /uuid. Envoy-based implementations such as Istio, Envoy Gateway and kgateway do full, case-sensitive matches.
2. use-regex applies to the whole host. Setting the annotation on one Ingress turns every path for that host into a regex, across all Ingresses, including paths declared as Exact.
3. rewrite-target implies regex. The rewrite annotation silently enables the same regex behavior for the host.
4. Missing trailing slashes are redirected. When a rule is defined as /my-path/, a request for /my-path gets a redirect to the version with the slash.
5. URLs are normalized before matching. Dot segments are resolved and repeated slashes collapsed, so a request for /ip/abc/../../uuid reaches an Exact /uuid rule and ////uuid is redirected to /uuid. Gateway API implementations normalize paths to different degrees, so check the one you pick.

A practical migration order

1. Inventory every cluster, IngressClass and Helm release that uses the controller, including managed add-ons.
2. Export Ingress objects, the controller ConfigMap and all annotations, and flag snippets, regex paths and rewrites.
3. Choose a Gateway API implementation or Ingress controller and install it alongside ingress-nginx with its own load balancer address.
4. Generate Gateway API resources with Ingress2Gateway and work through every warning.
5. Run test suites or replayed traffic against both addresses, checking the five behaviors above plus TLS, timeouts and request body limits.
6. Shift DNS gradually, keep the old controller running until traffic drains, then remove it together with its admission webhook and RBAC objects.

Kubernetes networking changes and platform releases are tracked in our DevOps platforms and networks sections, and new flaws in edge components in vulnerabilities.

Frequently asked questions

Is ingress-nginx deprecated or retired?

It is retired. Maintenance ended in March 2026, the final releases came out on March 19, 2026, and the GitHub repository is archived, so no further releases or security fixes will follow.

Will my existing ingress-nginx installation stop working?

No. Existing deployments keep running and the container images and Helm charts remain available. The risk is that any vulnerability discovered from now on stays unpatched.

Is the Kubernetes Ingress API being removed?

No. The Ingress API is frozen but generally available, and the Kubernetes project has no plans to remove it. New features are added to Gateway API instead.

Is F5 NGINX Ingress Controller affected by the retirement?

No. F5's NGINX Ingress Controller is a separate project; it uses NGINX as its data plane like the community controller but is otherwise unrelated.

What should replace ingress-nginx?

The Kubernetes project recommends a Gateway API implementation, or another maintained Ingress controller if you must keep the Ingress API. The right choice depends on which annotations and behaviors your services rely on, which Ingress2Gateway helps surface.