NGINX Ingress Controller End of Maintenance by March 2026

The community ingress-nginx controller has been the default entrypoint for routing traffic inside Kubernetes clusters for years. It’s widely adopted across startups, scale-ups, and enterprise production systems.

However, maintainers have announced that the project will move into end-of-life mode and stop being actively maintained by March 2026. Parts of the NGINX Kubernetes ecosystem are already deprecated or archived. This shift has significant implications for teams operating Kubernetes at scale.

Why ingress-nginx is reaching end-of-life

1. Transition to the Gateway API

Kubernetes networking has evolved beyond the legacy Ingress resource. The Gateway API provides a more modern, extensible, and consistent traffic management model. It offers:

• Native L4 and L7 routing support
• First-class support for HTTP, gRPC, TCP, and UDP
• Standardized policies and multi-tenant capabilities
• Cleaner configuration without annotation sprawl

This is where the ecosystem is investing - not in extending the legacy model.

2. Rising maintenance complexity

Keeping ingress-nginx aligned across Kubernetes versions, NGINX releases, Helm, and patch streams has become increasingly difficult. Recent high-severity vulnerabilities exposed how heavy the maintenance load has become and made the sustainability limits clear.

3. Fragmentation of routing technologies

Organizations today mix:

• NGINX OSS / NGINX Plus
• Envoy-based gateways (Kong, Ambassador, Gloo, Istio)
• Cloud-native gateway controllers (AWS, GCP, Azure)

The community version of ingress-nginx is no longer the strategic foundation for future networking.

What this means for production workloads

If you rely on ingress-nginx today, the risks include:

• Security exposure once support ends
• Compatibility drift with upcoming Kubernetes releases
• No feature evolution
• Operational fatigue for DevOps and platform teams

A migration path toward Gateway API-based controllers is recommended.

What you should do now

1. Audit your clusters: Identify where ingress-nginx is deployed and bound to automation pipelines.
2. Define your replacement strategy: Examples:
   
   1. Gateway API controllers from cloud providers
      
   2. Envoy-based gateways
   3. NGINX Plus (commercial path)
3. Prioritize simplicity: Teams should not spend weeks maintaining routing plumbing.

What does it mean for Qovery users?

If your Kubernetes clusters are:

• ‍managed by Qovery: you don’t need to take any action. Qovery will replace ingress-nginx in Q1 2026 with the new routing layer based on the Gateway API without downtime or service interruption.‍
• self-managed Kubernetes cluster: contact your Qovery Customer Success Manager so we can review your environment and support your migration.

If you’re tired of maintaining Kubernetes networking internals

We built Qovery to abstract infrastructure complexity and avoid forcing teams to chase breaking changes, API deprecations, and networking rewrites.

With Qovery:

• No ingress/gateway manual operations
• No upgrade maintenance windows
• Automated routing configuration and certificate lifecycle
• No need for platform teams to track Kubernetes API evolution

Your engineering team focuses on delivering value - not babysitting controllers.

If you want help assessing your current ingress setup or defining a gateway migration plan, we’d be happy to support you.