For most of Kubernetes' history, exposing a service to the outside world meant writing an Ingress resource and letting a controller, very often Ingress NGINX, become your cluster's front door. In fact, as of January 2026, “about 50% of cloud native environments” rely on Ingress NGINX.

In March 2026, the Kubernetes community archived the Ingress NGINX project. The controller still works and it is still running in a large share of production clusters. Teams must now make the decision they kept deferring: stay on the Ingress API or move to Gateway API. This article compares the two models: what each buys you, what each costs, and how to sequence a move without putting production traffic at risk.

TL;DR

● Archiving Ingress NGINX broke nothing, which is why so many clusters still run it. It did end security patching. Because the controller compiles NGINX into its own binary, fixes from upstream NGINX and the community no longer reach it.

● Ingress and Gateway API are not two syntaxes for the same thing. Ingress is a monolithic, frozen, layer-seven (L7)-only interface extended by controller-specific annotations. Gateway API is a live spec defining role-separated components with portable, expressive routing at both L4 and L7.

● Moving between them is a re-architecture, not a swap. Secure the controller you have, then translate, validate, and cut over on your own schedule.

What ‘archived’ means for an Ingress Controller

An archived repository is frozen, not deleted. The code that was there in March is still there, still buildable, still deployable. What disappeared is the group of people who developed it and responded when something broke.

For most software, that is bad enough. For this controller it is worse because of how it is built. Ingress NGINX does not call out to a separate NGINX process; it compiles NGINX into its own binary and ships the result as a single container image. When the NGINX project fixes a flaw in the web server, that fix only lands in the next NGINX release. There is no longer an upstream maintainer to rebuild the ingress controller with the fix.

This is not a theoretical problem. This year has already produced two examples. CVE-2026-42945, a heap buffer overflow in the NGINX rewrite module present in the code since 2008, is reachable before authentication, and rated 9.2 on CVSS v4.0. CVE-2026-42055 is another 9.2 in the HTTP/2 and gRPC upstream modules. Both are fixed in NGINX. Neither fix exists in upstream Ingress NGINX.

Find out what you are running

The inventory takes 10 seconds:

kubectl get pods --all-namespaces \
--selector=app.kubernetes.io/name=ingress-nginx \
--output='custom-columns=NAMESPACE:.metadata.namespace,IMAGES:.spec.containers[*].image'

Any controller image from registry.k8s.io/ingress-nginx/controller is the archived project, regardless of how recent the tag looks. Two neighbors cause confusion. F5's nginxinc/kubernetes-ingress is a separate controller, available in open source and commercial editions, and actively maintained. The NGINX web server itself is unaffected by the archive. Only the community controller is retired.

The face-off: Ingress API vs Gateway API

Both APIs answer the same question: how does traffic from outside the cluster reach a service inside it? They answer it with different assumptions about who owns what.

Resource model. Ingress is one object: host rules, paths, and a backend, with an IngressClass to pick the controller. Everything beyond that (rewrites, timeouts, TLS behavior, rate limits) lives in annotations that each controller defines for itself. Gateway API splits the job into three: a GatewayClass owned by whoever provides the infrastructure, a Gateway owned by the platform team that decides which listeners exist, and HTTPRoutes owned by application teams that decide where traffic goes. That separation aligns with how most organizations are actually structured.

Portability: An Ingress manifest that leans on controller-specific annotations is not very portable. Swap controllers and those annotations may stop working. Public Helm chart maintainers feel this directly: a chart that templates Ingress resources with NGINX-specific annotations breaks the moment a user swaps controllers. Adding Gateway API support means maintaining both templates until the ecosystem finishes moving. Gateway API was designed with that history in mind. The situations that required controller-specific annotations to work around Ingress limitations (header and method matching, weighted traffic splits, redirects, request modification) are core parts of the spec, so an HTTPRoute written for one implementation generally works on another.

Maturity: Ingress has a decade of tooling, examples, and operational support behind it. Nearly every how-to for getting traffic into a cluster is written against Ingress. That inertia is a legitimate advantage. Gateway API reached v1.0 in late 2023 and now has broad support, but some advanced features remain experimental.

Migration cost: The ingress2gateway tool translates the shape of Ingress resources into Gateway API equivalents and saves real time. It does not translate every controller-specific annotation, rewrite rule, or the behaviors applications have come to depend on without anyone documenting them. Every route needs a human to look at it once.

Where each wins: If you run a small environment with simple host and path routing, or you consume many public Helm charts that ship Ingress templates, moving to another maintained Ingress controller is the cheaper path; forking every chart to add Gateway API support is rarely worth it.

If you run a multiteam platform, are building new clusters, or expect to be operating this in five years, Gateway API is the better direction.

The two are not mutually exclusive. Several controllers, Traefik and Kong among them, implement both APIs, so a team can adopt one controller now, keep existing Ingress resources working, and move routes to Gateway API incrementally.

Sequencing the move

Since the archive, the most common mistake has been to treat the migration itself as the security fix. It is not. Swapping the controller on the production request path under pressure tends to replace a vulnerability finding with an outage. Treat the exposure and the migration as two separate problems.

Secure first. Teams have four realistic options for the controller they are running today: take on patching themselves, adopt a maintained community fork, use a commercially maintained build of the same controller, or go straight to the Gateway API. Which one fits depends on how much annotation debt you carry and how long the migration will honestly take. PCI DSS 4.0, ISO 27001, SOC 2, and HIPAA all carry requirements around the detection and remediation of vulnerable software, and none of them are satisfied by a component that can no longer receive fixes.

Then translate, validate, and cut over. Run ingress2gateway to get a first draft of your routes, reconcile every annotation by hand, and run the new Gateway alongside the old controller with a fraction of traffic before moving the DNS. Teams with simple routing finish in a quarter or two. Teams with heavy annotation use, customer commitments, or regulated change windows take longer, and that is fine once the controller underneath them is supported.

The decision was inevitable

The Ingress versus Gateway question predates the archive decision by years. What the retirement changed is that deferring now carries consequences. Every cluster still running the community Ingress NGINX controller is carrying unpatched vulnerabilities in the one component that sees every incoming request.

Find out what you are running, get it supported, and then choose the destination based on what your platform needs.

The archive did not create the decision. It removed the option of not making it.