End of Support for Ingress NGINX: Act Now on Your Migration Strategy

If you currently rely on Ingress NGINX as a central gateway and reverse proxy for external traffic to your applications in Kubernetes, we strongly recommend a structured migration as soon as possible to minimize security risks and downtime. In this blog post, we outline viable alternatives and walk you through predictable migration paths — including the transition to the newer Gateway API standard.

What Exactly Does the End of Support for Ingress NGINX Mean?

Updates for Ingress NGINX are already being released solely on a best-effort basis, which will likely be limited to security fixes. No new features will be developed, and once support officially ends in March 2026, even security updates will be discontinued. This marks the end of one of the most widely used Kubernetes Ingress controllers.

As of November 2025, roughly four months remain for organizations to migrate. It is therefore crucial to define and implement a structured migration plan as early as possible. Key considerations include evaluating suitable alternatives and deciding whether now is the right time to transition from the traditional Ingress model to the newer Gateway API standard.

Ingress vs. Gateway API

The most notable difference between Gateway API and Ingress is Gateway API’s strict separation of concerns.

• A single Ingress resource bundles host/path rules and listener ports for traffic routing together with infrastructural aspects such as controller configuration.
• Gateway API, in contrast, separates responsibilities across multiple resources: GatewayClass and Gateway for platform operations, while developers define routing rules for their applications using e.g. HTTPRoute resources.

Another major difference: Gateway API natively supports many advanced features that previously required controller-specific annotations in Ingress resources. This significantly reduces configuration dependency on specific controllers and enables more flexible controller changes. A simple example is HTTPS redirection. In Ingress NGINX, HTTPS redirect is configured via an annotation:

...

metadata:

 annotations:

   nginx.ingress.kubernetes.io/force-ssl-redirect: "true"

...

(see: https://kubernetes.github.io/ingress-nginx/user-guide/tls/#server-side-https-enforcement-through-redirect)

‍

In Gateway API, the same behavior can be configured directly in an HTTPRoute resource using a RequestRedirect filter:

...

spec:

 rules:

 - filters:

   - type: RequestRedirect

     requestRedirect:

       scheme: https

       statusCode: 301

...

(see: https://gateway-api.sigs.k8s.io/guides/http-redirect-rewrite/#redirects)

‍

These and other capabilities clearly favor adopting Gateway API over the traditional Ingress model. However, migration requires considerable effort, and infrastructure code complexity will increase. Since Kubernetes will continue supporting Ingress resources, switching to Gateway API is not mandatory now — but depending on your requirements and future plans, it can be a strategically valuable step.

For these reasons, we recommend choosing controllers that support both Ingress and Gateway API and provide explicit migration paths from Ingress NGINX. This enables a gradual, low-risk transition.

Alternative Ingress / Gateway Controllers

Several controllers are available as replacements for Ingress NGINX. The best option depends on your specific use case and should be evaluated on a case-by-case basis. Below is a concise overview of selected options.

F5 NGINX Ingress Controller

A straightforward option is the NGINX Ingress Controller by F5. It offers many similarities to Ingress NGINX, including comparable annotations, and provides a defined migration path.

However, it does not support Gateway API resources. To use Gateway API, the F5 NGINX Gateway Fabric needs to be deployed. Both products are available as open-source software under the Apache-2.0 license and work with open-source NGINX (https://github.com/nginx/nginx, BSD-2-Clause license). Additional enterprise features are available with NGINX Plus.

Traefik

Traefik aims to provide an easy drop-in replacement by leveraging its Ingress NGINX provider, which enables support for Ingress NGINX annotations in existing Ingress resources. After switching controllers, you can continue using your current Ingress definitions and migrate to Traefik-specific configurations at your own pace.

Traefik Proxy supports both Ingress and Gateway API resources. It is available as open-source software under the MIT license, with additional features such as Traefik Hub and support services available through commercial licensing.

HAProxy

The HAProxy Ingress Controller was developed as an alternative to Ingress NGINX and follows a similar annotation approach. However, it is not a direct drop-in replacement due to differences in certain configuration behaviors. HAProxy offers powerful load balancing and high throughput. The HAProxy Unified Gateway enables parallel use of both Ingress and Gateway API resources, though it is currently still in beta. Both components are available as open-source software under the Apache-2.0 license, with additional commercial licensing options.

Envoy Gateway

Envoy Gateway is built natively for Gateway API. For migrating existing Ingress NGINX setups, the tool “ingress2gateway” automatically converts existing Ingress resources into Envoy-compatible Gateway API resources. Envoy Gateway is available as open-source software under the Apache-2.0 license.

Conclusion: Time to Take Action

The upcoming end of support for Ingress NGINX requires timely action: planning and gradually executing the Ingress controller migration should begin as soon as possible. While Gateway API offers advantages in governance, portability, and functionality, it also increases infrastructure complexity. Whether you adopt Gateway API now should depend on your platform and infrastructure strategy. Since Kubernetes will continue to support classic Ingress resources, focusing on replacing the NGINX Ingress Controller itself is a valid option.

In practice, the best approach in many cases is choosing a controller that supports both Ingress and Gateway API and offers smooth migration paths from Ingress NGINX. This provides flexibility and makes the currently optional introduction of Gateway API significantly easier.