TL;DR

• Ingress NGINX (community ingress-nginx) is retiring, with best-effort maintenance only until March 2026.
• After EOL: no releases, bugfixes, or security/CVE patches—running it in prod becomes a growing security risk.
• Recommended direction: start moving to Gateway API (or another actively maintained controller) now.

The Kubernetes community has announced the official retirement of the widely used, community-maintained Ingress NGINX controller, confirming a significant shift in the Kubernetes networking ecosystem. This migration carries important implications for engineers currently relying on this component.

The Critical Timeline: March 2026 End-of-Life

Active, best-effort maintenance for the Ingress NGINX project will continue only until March 2026, the official Ingress NGINX end-of-life date.

After this date, the project will be fully retired. This means there will be:

• No further releases.
• No bugfixes.
• No security patches or CVE fixes.
• No updates to resolve any security vulnerabilities that may be discovered in the future.

While existing deployments will continue to function and installation artifacts will remain available, running production workloads on a deprecated Ingress NGINX controller beyond EOL will carry increasing security and operational risks.

Why the Project is Retiring

Ingress NGINX became exceptionally popular early in the Kubernetes project due to its flexibility and feature breadth. However, this popularity was not matched by sustainable maintenance efforts.

• Maintainer Burnout: For years, the project relied on a tiny team of volunteers—often just one or two people—working in their spare time. This dedication was impressive, but the team faced an "endless flood of bugs and feature requests" and eventual burnout.
• Technical Debt: The flexibility once valued has become "insurmountable technical debt". Features like the ability to add arbitrary NGINX configuration directives via "snippets" annotations are now viewed as potential security flaws.
• Failed Replacement: The planned replacement, InGate, never progressed far enough to become a mature alternative and will also be retired.

These factors combined to solidify the decision behind the Ingress NGINX retirement.

The Recommended Migration Path

The official recommendation from the Kubernetes SIG Network and the Security Response Committee is to immediately begin migration to the Gateway API or another actively maintained Ingress controller.

Why Gateway API Is the Future

The Gateway API is considered the modern, persona-driven replacement for the older Ingress resource, reflecting the evolution of Kubernetes networking.

Key advantages of migrating to Gateway API include:

• Expressive Routing: Provides first-class support for advanced traffic features like filters, rewrites, timeouts, retries, and header manipulation.
• Separation of Concerns: Offers a clear distinction between the responsibilities of platform administrators and application teams.
• Future-Proof: Provides alignment with the long-term Kubernetes networking roadmap.
• Broad Support: It supports native L4 and L7 routing for protocols like HTTP, gRPC, TCP, and UDP.

Important Note on Certificate Management

When transitioning to the Gateway API, platform teams should be aware that it standardizes on defining certificates on the Gateway instance, rather than the application-specific HTTPRoute (the Ingress equivalent). This design change means deploying applications with new certificates often requires a two-step process involving an update to the central Gateway resource, potentially breaking self-contained deployment automation.

Migration Alternatives for Platform Engineers After Ingress NGINX Deprecation

For teams needing a stable, actively maintained replacement, several options are available:

1. Remaining on the NGINX Engine (The Open Source NGINX Ingress Controller)

If your team prioritizes the familiarity of the NGINX data plane, the Open Source NGINX Ingress Controller (NIC) maintained by F5 is a viable option.

• Different Project: It is essential to note that this is a separate, actively maintained project from the community-based ingress-nginx that is being retired.
• Smoother Transition: NIC uses the same NGINX engine, minimizing the learning curve. It provides a detailed migration guide with clear mappings for most existing ingress-nginx annotations.
• Cleaner Configuration: NIC offers Custom Resource Definitions (CRDs) like VirtualServer and Policy for configuration, which can reduce the reliance on annotation sprawl common in the retiring controller.
• Future Path: NIC also provides a clear migration path to the Gateway API through the NGINX Gateway Fabric (NGF) when the time comes.

2. Adopting Gateway API Implementations

For teams focused on adopting the future Kubernetes standard, several mature open-source projects implement the Gateway API:

• Contour: This CNCF-backed project, which uses Envoy as its data plane, is often cited for strong performance at scale. It simplifies configuration by using the HTTPProxy resource to separate concerns among teams.
• Kong Gateway: Kong offers the open-source utility ingress2gateway to automatically translate existing Ingress NGINX resources into Gateway API resources, helping to accelerate migration. The Kong Operator also supports both Ingress and Gateway API simultaneously, providing a flexible migration runway.
• Cilium: If Cilium is used as the CNI, it provides a built-in ingress controller and Gateway API support for various use cases.
• Istio: If your organization already uses Istio as a service mesh, using it as the Gateway Controller is generally recommended for consistency and simplifies external traffic management. Istio also implements mTLS for both Ingress and Gateway API.
• Traefik: Often noted as a potentially drop-in replacement, Traefik offers an ingress NGINX compatibility layer for annotations,  but users report mixed results depending on the complexity of their configurations.

3. Other Contenders

• HAProxy: HAProxy Technologies announced the HAProxy Unified Gateway, which supports both Ingress and the Gateway API, aiming to provide a highly compatible and straightforward migration path.
• Cloud Native Solutions: Users of public clouds can leverage native solutions like Azure's Application Gateway for Containers (the successor to AGIC).

Action Plan for Platform Teams

Given the lack of security updates after March 2026, teams must prioritize this work:

1. Identify Usage: Audit all clusters to confirm where ingress-nginx is deployed, typically using a selector like kubectl get pods --all-namespaces --selector app.kubernetes.io/name=ingress-nginx.
2. Define Strategy: Select an appropriate replacement (Gateway API implementations or a maintained Ingress controller like NIC) based on future needs and team familiarity.
3. Implement and Test: Install the new controller alongside the existing one and gradually shift traffic, verifying that all functionality (routing, SSL, rate limiting) and performance are correct before decommissioning the retired controller.

Preparing for a Post–Ingress NGINX Era

The Ingress NGINX deprecation is a major turning point for Kubernetes networking. Proactive migration minimizes the operational burden and prevents security risks from accumulating due to lack of maintenance. The retirement of Ingress NGINX marks a necessary transition toward more sustainable and feature-rich Kubernetes networking solutions.