Cloud Native 6 min read

Why Ingress NGINX Is Retiring and How to Migrate to Gateway API

Ingress NGINX will be officially retired in March 2026 with no further releases or security fixes, prompting users to migrate to alternatives like the modern Gateway API or other supported Ingress controllers to maintain cluster security and functionality.

Linux Ops Smart Journey
Linux Ops Smart Journey
Linux Ops Smart Journey
Why Ingress NGINX Is Retiring and How to Migrate to Gateway API

Retirement Announcement

The Kubernetes SIG Network and Security Response Committee announced that the Ingress NGINX controller will be retired. Best‑effort maintenance continues until 31 March 2026; after that no new releases, bug fixes, or security patches will be provided.

Impact on Existing Deployments

Existing Ingress NGINX installations will keep running. Helm charts, container images, and other installation artifacts remain available in public registries. The GitHub repository will be switched to read‑only mode for reference only.

Technical Background

Ingress NGINX was one of the earliest Ingress controllers, valued for its cloud‑agnostic design and extensive feature set. Its flexibility allowed users to inject arbitrary NGINX directives via “snippets”, which later became a security liability. The project was maintained by a very small number of contributors working part‑time, limiting its capacity to address growing user demand and security concerns.

Current Status

As of now the project is under best‑effort maintenance. The SIG is seeking additional maintainers, but the priority is to protect the ecosystem, so the controller will be retired in March 2026.

Migration Recommendations

Users should begin migrating as soon as possible. Recommended options include:

Adopt the Gateway API , which provides a more modern and extensible model for traffic routing.

Choose an alternative Ingress controller that fits the target environment (e.g., cloud‑provider specific or generic open‑source controllers) as listed in the official Kubernetes documentation.

A typical migration path to the Gateway API involves:

Install the Gateway API CRDs (e.g.,

kubectl apply -f https://github.com/kubernetes-sigs/gateway-api/releases/download/v0.8.0/standard-install.yaml

).

Deploy a Gateway‑API‑compatible controller (such as contour or istio).

Replace existing Ingress resources with Gateway and HTTPRoute resources, preserving host, path, and TLS settings.

Validate traffic flow and decommission the Ingress NGINX controller.

All existing Helm charts and container images for Ingress NGINX will remain accessible for the duration of the maintenance window, allowing a gradual transition.

References

For a complete list of supported replacement controllers, see the “Ingress Controllers” section of the Kubernetes documentation.

cloud-nativeKubernetesNetworkingGateway APIdeprecationingress-nginx
Linux Ops Smart Journey
Written by

Linux Ops Smart Journey

The operations journey never stops—pursuing excellence endlessly.

0 followers
Reader feedback

How this landed with the community

Sign in to like

Rate this article

Was this worth your time?

Sign in to rate
Discussion

0 Comments

Thoughtful readers leave field notes, pushback, and hard-won operational detail here.