Ingress NGINX End of Life: What It Means and How to Migrate

The ingress NGINX end of life means the controller still routing traffic in many clusters will no longer receive security patches, because Kubernetes archived the community ingress-nginx repository in March 2026. Moving off it is also a chance to modernize your cluster edge, since the same migration can tighten your permission model and reduce exposure.

This guide covers what the retirement changes for your running cluster, the three structural paths off ingress-nginx, and a phased plan for cutting over without dropping production traffic.

What Is the Ingress NGINX End of Life and When Does It Take Effect?

End of life took effect on March 24, 2026, when Kubernetes archived the ingress-nginx repository, four months after announcing the retirement on November 11, 2025. The final controller release, v1.15.1, shipped on March 19, 2026. Kubernetes' retirement announcement gives end of life a precise meaning: "no further releases, no bug fixes, and no updates to resolve any security vulnerabilities that may be discovered."

Existing deployments keep running, Helm charts and container images stay downloadable, and the archived repository stays readable for reference. The repository's final README support matrix lists Kubernetes 1.31 to 1.35 for v1.15.1, which makes 1.35 the last minor version the project tested. Kubernetes' January 2026 statement put the controller in about half of cloud native environments, based on vendor research.

Why Is Ingress NGINX Being Retired?

Ingress NGINX is being retired because, for a long time, only one or two people maintained it in their free time, and repeated calls for contributors never brought enough help. InGate, the planned replacement, never matured and is being retired too.

Kubernetes' January statement adds that technical debt and "fundamental design decisions that exacerbate security flaws" made continued maintenance unreasonable even if resources appeared. The retirement announcement names the "snippets" annotations, which accept arbitrary NGINX configuration directives, as an example of flexibility that became a security liability.

The Ingress API itself already has a successor. Gateway API reached general availability on October 31, 2023, when Gateway, GatewayClass, and HTTPRoute graduated to stable. Its role-oriented design gives cluster operators ownership of Gateways and application teams ownership of HTTPRoutes.

Ingress offers little beyond TLS termination and simple routing, relies on annotations for implementation-specific extensions, and has a permission model too coarse for multi-team clusters. Kubernetes urges ingress-nginx users to begin migrating to Gateway API or another Ingress controller immediately.

What Are the Risks of Running Ingress NGINX After End of Life?

Running ingress-nginx after end of life means every vulnerability disclosed from now on stays open in your cluster. The final controller release fixed a comment-based NGINX configuration injection rated 8.8 High in the CVE-2026-4342 advisory, and no release will follow it. Three risks grow from there:

• Security degradation: The 2025 IngressNightmare disclosure shows the worst case. CVE-2025-1974 carried a 9.8 Critical rating in the IngressNightmare security advisory for unauthenticated remote code execution through the admission controller, reachable from anything on the pod network.
• Kubernetes version ceiling: The published matrix stops at 1.35, and Kubernetes v1.36 shipped after support ended. Nothing documents specific breakage beyond the matrix yet, but each minor you adopt moves the controller further outside what the project tested.
• Dependency rot: The final release bundles NGINX 1.27.1 and will stay on it, and the frozen build won't pick up upstream NGINX, Go, or Helm fixes.

None of these risks cause an immediate outage. Pods keep serving, and dashboards stay green while exposure accumulates, and the on-call engineer sees no warning until an incident exposes the missing security coverage.

What Are Your Ingress NGINX Migration Options?

You have three structural paths off ingress-nginx, and they differ in near-term effort and in who carries the security burden afterward. Your count of Ingress manifests and custom annotations determines the work, while the date of your next Kubernetes upgrade sets the deadline. The table compares the three paths:

1. Migrate to the Kubernetes Gateway API

Gateway API is the recommended long-term path because it replaces Ingress objects with three resources that separate shared gateway infrastructure from application routing rules:

• GatewayClass: Defines a class of gateways with shared configuration.
• Gateway: Requests a traffic entry point.
• HTTPRoute: Maps traffic to Services.

Envoy Gateway, Istio, Kong, Traefik, NGINX Gateway Fabric, Cilium, and Google Kubernetes Engine (GKE) appear as conformant implementations, and the AWS Load Balancer Controller supports Gateway API on Amazon EKS without a listed conformance level.

Moving to Gateway API means rewriting manifests, because Gateway API has no Ingress kind, and a hand-translated annotation that changes routing behavior can drop traffic at cutover. Ingress2gateway 1.0 shipped shortly before end of life, translates more than 30 common ingress-nginx annotations, and warns for each field it can't translate. You have to refactor or drop configuration-snippet, which has no portable equivalent.

2. Switch to the F5 NGINX Ingress Controller

The F5 NGINX Ingress Controller is the lower-effort path because your Ingress objects stay in place and mainly the annotation prefixes change. Despite the similar name, F5's controller is a separate project from the one Kubernetes retired. The retired kubernetes/ingress-nginx uses the nginx.ingress.kubernetes.io/ annotation prefix, while F5's NGINX Ingress Controller lives at nginx/kubernetes-ingress, uses nginx.org/, and remains actively maintained.

F5's controller changelog shows the 5.4.0 release in March 2026 focused on easing migrations from ingress-nginx, and 5.5.0 added Kubernetes 1.36 to its tested versions two months later. The API surface stays close, with differences such as force-ssl-redirect behavior mapping to nginx.org/redirect-to-https. Teams that can't rewrite to HTTPRoute before their next cluster upgrade can use the F5 controller as a bridge.

3. Fork or Self-Maintain the Controller

Forking ingress-nginx is the highest-risk option because no current fork has a documented multi-maintainer commitment or endorsement from Kubernetes or the CNCF. The maintenance-only EmeritOSS fork addresses CVEs on a best-efforts basis, and its pre-built, patched images are a commercial offering.

Running any fork means your team owns CVE triage as part of incident response, compatibility testing against each Kubernetes minor, and tracking upstream NGINX for a bundled binary the fork may not refresh. The Kubernetes project itself could not staff that workload.

How to Plan an Ingress NGINX Migration

Moving off ingress-nginx takes more work than a Helm upgrade, so plan it in four phases, starting with an audit, then evaluation, a non-production deployment, and a monitored cutover. Complete the audit before writing any manifests, because each phase narrows the choices for the next.

1. Audit Every Ingress Object Across Namespaces

Annotation usage decides which paths are open to you, so the audit comes first. Running ingress2gateway print --providers=ingress-nginx --all-namespaces produces Gateway API manifests for the whole cluster and flags each field it can't translate.

Classify Ingress objects with only host and path rules as plain routes, mark objects with supported annotations such as path rewrites and CORS as translatable, and set aside objects that use configuration-snippet for manual work. The resulting inventory shows you where the engineering time goes.

2. Evaluate Your Path Against Version, Annotations, and TLS

Kubernetes version sets urgency, because clusters above 1.35 already run the controller outside its tested matrix. Annotation usage sets effort, since anything outside ingress2gateway's supported list is implementation-specific and needs the target controller's own policy resources.

TLS ownership shapes the architecture. On a shared Gateway, every TLS change can become a ticket for the cluster operator, which is why teams with per-team cert-manager workflows may need the F5 bridge first. Cert-manager 1.20 added alpha support for issuing certificates from a ListenerSet, the Gateway API resource that lets teams attach their own listeners to a shared Gateway, but the feature is off by default.

3. Run the New Controller in Parallel in Non-Production

Running both controllers side by side in non-production first lets you validate each converted HTTPRoute with kubectl describe httproute and compare responses from both controllers. A CNCF member case study on moving to Envoy Gateway tested the dual setup locally and on an internal cluster first. The team then ran Ingress and HTTPRoute side by side in production behind weighted DNS, starting with all traffic on Ingress and keeping rollback to a weight swap.

Watch both stacks through your existing Kubernetes monitoring before moving any production traffic. In Coralogix, a cross-stack observability platform, Kubernetes dashboards show both controllers' request rates, 4xx and 5xx responses, and latency on one view during the parallel run.

4. Monitor the Cutover Across Request Rate, Errors, and Latency

The cutover needs request rate, error rate, and latency compared across both controllers for the whole window. Ingress-nginx exposes the nginx_ingress_controller_requests counter with host, namespace, service, and status labels, while Envoy Gateway serves Envoy proxy metrics on the /stats/prometheus admin endpoint and can push them to an OpenTelemetry sink, so the two arrive through different pipelines.

Shipping both through Prometheus Remote Write or an OpenTelemetry Collector puts them on one timeline. If 4xx and 5xx rates rise on the new endpoint while the old path stays flat, the routing change is the likely fault domain. A weighted DNS shift then lets you return traffic to the old controller while you fix the translation.

Which Ingress NGINX Migration Path Fits Your Clusters?

Kubernetes has archived ingress-nginx, so every month you keep running it leaves newly disclosed CVEs unpatched and widens the distance between your cluster version and the controller's last tested release. Gateway API is the Kubernetes-endorsed long-term path, and the F5 controller is a lower-effort bridge for teams whose annotation surface or TLS workflow isn't ready for HTTPRoute yet.

The right choice depends on your annotation inventory and TLS ownership model, and it should align with your upgrade schedule. Whichever path you pick, Coralogix keeps both controllers' metrics, logs, and traces on one timeline, which lets you tie an error or latency spike to the rollout step that caused it.

Explore the Coralogix platform to watch both controllers through your own cutover.

Frequently Asked Questions About Ingress NGINX End of Life

Is ingress NGINX being discontinued?

Yes, Kubernetes retired the community-maintained controller and archived its repository in March 2026, shortly after the final controller release. Existing installs keep routing traffic, but maintainers won't ship further security patches, dependency bumps, or compatibility fixes.

What will replace ingress NGINX?

Gateway API is the long-term replacement, implemented by conformant controllers such as Envoy Gateway, NGINX Gateway Fabric, Istio, and GKE's managed Gateway controller. If you need to stay on the Ingress API for now, the Kubernetes documentation lists other Ingress controllers, and F5's NGINX Ingress Controller is the closest match for ingress-nginx annotations.

Can ingress-nginx and Gateway API run in the same cluster?

Yes, Ingress and Gateway API are separate resource kinds handled by separate controllers, so both can serve traffic in one cluster during a migration. Each controller typically gets its own load balancer address, which is what lets a weighted DNS record shift traffic between them and shift it back if the new routes misbehave.

Is Ingress going to be deprecated?

No, the Ingress API is frozen but remains generally available, and the Kubernetes deprecation policy prevents removing generally available APIs within a major version. For ingress-nginx users, the practical effect resembles deprecation, because a widely deployed implementation no longer receives updates.