Ingress NGINX Controller Is Dead — Should You Move to Gateway API?

Now What? Understanding the Impact of the Ingress NGINX Deprecation

Ingress NGINX Controller, the trusty staple of countless platform engineering toolkits, is about to be put out to pasture. This news was announced by the Kubernetes community recently, and very quickly circulated throughout the cloud-native space. It’s big news for any platform team that currently uses the NGINX Controller because, as of March 26, 2026, there will be no more bug fixes, no more critical vulnerability patches and no more enhancements when Kubernetes continues to release new versions.

If you’re feeling ambushed, you’re not alone. For many teams, this isn’t just an inconvenient roadmap update, its unexpected news that now puts long-term traffic management decisions front and center. You know you need to migrate yesterday but the best path forward can be a confusing labyrinth of platforms and unfamiliar tools. Questions you might ask yourself:

❓Do you find a quick drop-in Ingress replacement?

❓Does moving to Gateway API make sense and can you commit enough resources to do a full migration?

❓If you decide on Gateway API then what is the best option for a smooth transition?

With Ingress NGINX on the way out, platform teams are standing at a familiar but uncomfortable moment: deciding whether to stick with what works today or invest in what will carry them forward tomorrow.

A Fork in the Road: Choosing Your Path Beyond Ingress NGINX

Ingress API continues to serve as a solid and reliable solution for straightforward routing needs. Gateway API builds on that foundation with a more expressive, extensible, and standardized model suited for modern production environments. To understand what’s really at stake, it helps to look beyond the headlines and compare what Ingress and Gateway API actually offer in practice.

The chart below shows how the two compare across key features.

Key Benefits Summary:

Ingress API (Basic): Ideal for simpler, smaller applications or teams that don’t need advanced traffic management or cross-namespace operations. It’s easy to set up and good for basic use cases.

Gateway API (Advanced): Perfect for complex, large-scale microservices environments. The Gateway API is highly extensible, supports advanced traffic management features, and centralizes configuration, making it better suited for scalable and secure infrastructure.

Looking at a side-by-side comparison of Ingress API vs. Gateway API shows that Gateway API provides a wider range of features for more advanced traffic management needs.

Features alone don’t make the decision, though. The right path depends just as much on your organization’s scale, risk tolerance, and operational maturity

Choosing Your Path Forward: Ingress or Gateway API?

While the Kubernetes world is leaning towards the more feature-rich and future-proof Gateway API, your migration path also depends on your use cases, the state of your Kubernetes clusters and the capability of your team to handle a learning curve. Resource constraints and legacy applications or tools that depend on Ingress play a part as well.

Here are some questions you can ask yourself when assessing the tradeoffs between staying on Ingress or committing to a migration to Gateway API:

Question: Are you a small organization with simple use cases and limited resources?

In this case going with a drop-in ingress controller makes sense. If all you need is a handful of path rules it might not be worth the effort to migrate to Gateway API for the foreseeable future as Kubernetes is not deprecating Ingress any time soon.

Q: Do you need a zero-change, low-risk migration?

Choose a drop-in Ingress controller for now but plan to re-evaluate and plan for a full migration to Gateway API at a later date. If you have a large number of Ingress resources to convert to HTTPRoutes you will want to consider automating the process.

Q: Are you already planning a modernization or are building new clusters?

If so, Gateway API is the clear choice moving forward. Popular Gateway API implementations include Kong Gateway, Gloo Gateway, and Istio. Calico Ingress Gateway, is another strong option, built on a production-hardened upstream Envoy distribution, and comes bundled with useful routing, security, and observability features. It can be enabled in just a few steps, making it an easy fit for modern cluster builds.

Q: Do you need complex routing rules?

While there are annotations that give you advanced traffic management functionality, the effort of mapping them to equivalent annotation in a new ingress controller is a strong argument for moving to Gateway API. The HTTPRoute resource offers native support for weighted traffic splitting, header/method matching, traffic mirroring and more.

Q: Do you need to route traffic securely between namespaces?

This is difficult to do with Ingress by design as cross-namespace routing can leave a cluster exposed to privilege escalation, unauthorized data access and by-passing of network policies, among other vulnerabilities. Gateway API provides a secure way to route traffic between namespaces.

Q: Do you need to secure public APIs?

Choose a Gateway API implementation that provides  rate limiting and WAF capabilities.

Q: Are you in an industry with higher than normal compliance or security requirements?

Choose a Gateway API implementation that not only allows you to secure Gateway API resources with RBAC but can apply network policy to traffic to and from your Gateway.

If you’re weighing several of these considerations at once, the decision can feel less like a checklist and more like a tradeoff analysis. The matrix below brings these questions together to help clarify which path makes the most sense for your environment.

The bottom line:  Gateway API is generally the more flexible and future-ready option but Ingress remains appropriate when it aligns well with your existing use cases and constraints.

Once you’ve weighed those tradeoffs, the remaining question becomes less about if you should modernize and then more about how to do it without unnecessary pain.

The Easy Path to Gateway API

The deprecation of Ingress NGINX Controller can be a catalyst for positive architectural change. If your cluster needs the advanced routing capabilities Gateway API provides (and most production clusters do), this is an opportunity not only to modernize your traffic management but to streamline your clusters for long term maintainability and cost savings.

If you decide on Gateway API (and industry trends indicate you should), the implementation you choose matters. Choose a solution that gives you more than just another bolted-on component, demanding additional management and separate configurations.  A unified platform that provides the capabilities essential for modern production environments. Built-in observability, native L7 security, and compatibility with service mesh and network policy are key to making the transition sustainable at scale.

To see what this looks like in practice, explore Calico Ingress Gateway, a production-ready Gateway API implementation designed to make adoption straightforward without sacrificing security or visibility.