Ingress-NGINX Is Being Retired — What Should You Move To?

·2 min readOriginally posted on LinkedIn
kubernetesdevops

If you're running ingress-nginx in production, this is something to pay attention to.

The community Kubernetes NGINX Ingress Controller is being retired, which over time means:

  • No guaranteed alignment with future Kubernetes releases
  • Increasing uncertainty around security fixes and CVE response
  • A critical data-plane dependency without a clear long-term owner

For years it was the default because it was simple and predictable to operate. But Kubernetes networking has moved on, and Ingress is no longer where the ecosystem is investing.

What are teams moving to instead?

NGINX Inc. Controller

A natural move if you want continuity, but with vendor backing and a defined support model.

Gateway API (where Kubernetes is clearly heading)

More expressive routing, fewer annotations, and a cleaner separation between platform and application concerns. Seeing adoption around Envoy Gateway, Kong, Traefik, Istio.

Cloud-native controllers (EKS/GKE/AKS)

Let the cloud handle L7, WAF, and scaling instead of rebuilding that layer inside the cluster.

The real story isn't "NGINX is going away". It's Kubernetes shifting from hand-managed ingress configs → platform-level traffic management.

Teams that treat this as just a controller swap may miss a chance to simplify their architecture.

Would love to understand how others are handling this: Moving toward Gateway API? Staying on NGINX with support? Pushing this responsibility back to the cloud edge?