When does ingress-nginx actually stop being maintained?

Kubernetes announced the retirement of Ingress NGINX on November 11, 2025, and the Kubernetes Steering Committee and Security Response Committee published a joint statement reaffirming it on January 29, 2026. Best-effort maintenance runs until March 2026. After that, per the project’s own GitHub README, there are no further releases, no bugfixes, and no updates to resolve any newly discovered security vulnerabilities.

Will my cluster break the day ingress-nginx retires?

No. The Kubernetes statement and the ingress-nginx README both say existing deployments will keep working, and the existing Helm charts and container images stay published — nothing is pulled. What stops is the safety net: any vulnerability discovered in the controller after retirement has nobody committed to patching it.

What does Kubernetes recommend instead of ingress-nginx?

The official statement points to Gateway API or one of the maintained third-party Ingress controllers listed in the Kubernetes documentation. It is explicit that none of the available alternatives are a direct drop-in replacement, and that migration takes real planning and engineering time — not a config flag.

Is there a tool that automates the migration?

Ingress2Gateway, which hit 1.0 in March 2026, converts Ingress resources — including ingress-nginx-specific annotations — into Gateway API resources with the `--providers=ingress-nginx` flag. It is a strong starting point, not a finished migration: Kubernetes itself publishes a list of edge cases and unexpected defaults worth reading before you rely on the output.

Kubernetes networking

Kubernetes Ingress NGINX End of Life: Now What?

Kubernetes is retiring the ingress-nginx controller in March 2026. Here is what that actually means, how to check what your cluster is running, and the migration options worth weighing before the next CVE has nobody to fix it.

By Muhammad Soliman, Founder at SeaGit · Published 19 September 2026

Start free Clusters documentation

Is ingress-nginx really end of life?

Yes. On January 29, 2026, the Kubernetes Steering Committee and Security Response Committee published a statement confirming that Ingress NGINX — the controller roughly half of Kubernetes clusters run — retires in March 2026. The retirement was first announced on November 11, 2025, after years of public warnings that the project lacked enough maintainers. Best-effort maintenance continues until March 2026; after that, per the project's own README, there are no further releases, no bugfixes, and no patches for newly discovered vulnerabilities. Existing installations are not deleted — nothing breaks on the retirement date — and existing Helm charts and container images stay published. What changes is who fixes the next CVE: nobody is committed to it. Kubernetes' own guidance is to start migrating to Gateway API or another maintained Ingress controller now, since none of the alternatives are a drop-in replacement.

What "end of life" means for ingress-nginx

What keeps working

• A cluster running ingress-nginx today keeps routing traffic after March 2026 — retirement does not uninstall it
• Published Helm charts and container images stay available
• Existing Ingress resources and annotations keep being honored by the last release

What stops

• No more releases of any kind, including security releases
• No fixes for CVEs discovered in the controller after the cutoff
• No new Kubernetes API compatibility work as newer cluster versions ship

How to tell whether you're running ingress-nginx

Before deciding anything, confirm what is actually deployed — "ingress" and "ingress-nginx" are not the same thing, and plenty of clusters run a different controller (or more than one) under a similar-looking IngressClass name.

# Is an ingress-nginx controller pod running, and where?
kubectl get pods --all-namespaces -l app.kubernetes.io/name=ingress-nginx

# Which IngressClass(es) exist, and which controller owns each one?
kubectl get ingressclass -o wide

# What image — and therefore what version — is it running?
kubectl get deployment -n ingress-nginx ingress-nginx-controller \
  -o jsonpath='{.spec.template.spec.containers[0].image}'

# Which of your Ingress resources actually point at it?
kubectl get ingress --all-namespaces \
  -o jsonpath='{range .items[*]}{.metadata.namespace}{"/"}{.metadata.name}{" -> "}{.spec.ingressClassName}{"\n"}{end}'

If nothing matches the first command, you are not affected by this specific retirement — though it is worth checking whether whatever you do run has a maintenance story of its own. If something does match, the last command tells you how many services actually depend on it, which is the real scope of the migration.

Your migration options

Gateway API — the path Kubernetes points to

The Kubernetes statement names Gateway API as the project's designated successor to the Ingress resource. It splits what a single Ingress annotation used to do across a few explicit resources — a GatewayClass and Gateway for the load balancer and listeners, HTTPRoute (and friends) for the routing rules — which trades a smaller, simpler API for one with real behavior differences and no shared annotation dialect to fall back on. It is a real migration, not a search-and-replace on your Ingress YAML.

AWS Load Balancer Controller — the AWS-native option on EKS

If your clusters run on Amazon EKS, the AWS Load Balancer Controller is a separately maintained project that provisions an Application Load Balancer for your Ingress resources instead of running nginx in-cluster. It is unaffected by the ingress-nginx retirement because it is a different codebase with different maintainers — but switching to it is still a migration: its own IngressClass (alb) and its own annotation set replace ingress-nginx's, so behavior for path rewrites, redirects and rate limiting has to be re-verified, not assumed.

A different maintained Ingress controller

The Kubernetes statement also points at the official catalog of Ingress controllers as a valid path — staying on the Ingress API, just with a controller that has active maintainers. This is the lowest short-term disruption option if your priority is closing the security gap without also absorbing a Gateway API rewrite at the same time, though it does not remove the longer-term question of where the ecosystem is heading.

Ingress2Gateway — a conversion tool, not a finished migration

Ingress2Gateway reached 1.0 in March 2026 and can translate Ingress manifests — including ingress-nginx-specific annotations, via --providers=ingress-nginx — into Gateway API resources, reading either from files or directly from a live cluster. It shortens the conversion, but Kubernetes itself publishes a list of edge cases and unexpected defaults in ingress-nginx configurations worth reading before you trust the generated output in production.

What happens if you do nothing

Nothing forces your cluster to change on the retirement date — and that is precisely the risk. The Kubernetes statement is blunt about it: remaining on ingress-nginx after retirement "leaves you and your users vulnerable to attack", because the next vulnerability discovered in the controller has no one committed to patching it. That risk does not arrive on a fixed schedule — it depends entirely on when a researcher or an attacker finds the next issue, which could be soon or could be a long time from now. Planning the migration before that happens is the difference between a scheduled cutover and an incident response.

Where this fits if you don't have a platform team

An ingress controller migration is exactly the kind of day-2 cluster work that stalls when nobody owns the platform layer full time — it is not urgent until it suddenly is, and it touches every service behind the load balancer at once. SeaGit provisions Amazon EKS clusters inside your own AWS account and manages the ingress controller, cert-manager and external-dns as add-ons on top of the clusters it provisions, which is the layer a controller swap actually lives in. Cloud support today is AWS only; Azure and GCP are on the roadmap, not available now.

On the successor question specifically: Gateway API is replacing the NGINX ingress add-on on SeaGit clusters, and the change is scheduled to roll out automatically to SeaGit-managed clusters by 1 October 2026. For those clusters the deadline at the top of this post is already handled — the move is a managed upgrade of the ingress add-on rather than a project each team scopes and runs alone. If you manage your own clusters, the options above are the path.

If you want to test a new ingress controller against real traffic rules before cutting over the production path, that is also what preview environments are for — a separate, real deployment with its own DNS subdomain and no traffic impact on the main one while you verify behavior.

Ingress NGINX end of life — FAQ

When does ingress-nginx actually stop being maintained?: Kubernetes announced the retirement of Ingress NGINX on November 11, 2025, and the Kubernetes Steering Committee and Security Response Committee published a joint statement reaffirming it on January 29, 2026. Best-effort maintenance runs until March 2026. After that, per the project’s own GitHub README, there are no further releases, no bugfixes, and no updates to resolve any newly discovered security vulnerabilities.
Will my cluster break the day ingress-nginx retires?: No. The Kubernetes statement and the ingress-nginx README both say existing deployments will keep working, and the existing Helm charts and container images stay published — nothing is pulled. What stops is the safety net: any vulnerability discovered in the controller after retirement has nobody committed to patching it.
What does Kubernetes recommend instead of ingress-nginx?: The official statement points to Gateway API or one of the maintained third-party Ingress controllers listed in the Kubernetes documentation. It is explicit that none of the available alternatives are a direct drop-in replacement, and that migration takes real planning and engineering time — not a config flag.
Is there a tool that automates the migration?: Ingress2Gateway, which hit 1.0 in March 2026, converts Ingress resources — including ingress-nginx-specific annotations — into Gateway API resources with the `--providers=ingress-nginx` flag. It is a strong starting point, not a finished migration: Kubernetes itself publishes a list of edge cases and unexpected defaults worth reading before you rely on the output.
Does SeaGit handle this for me?: Yes. Gateway API is replacing the NGINX ingress add-on on SeaGit clusters, and the change is scheduled to roll out automatically to SeaGit-managed clusters by 1 October 2026 — customers do not have to plan or run the migration themselves. SeaGit provisions Amazon EKS clusters inside your own AWS account and manages the ingress controller, cert-manager and external-dns as add-ons on top of them, so a controller swap is a managed upgrade of that add-on layer rather than an unowned fire drill. See bring your own cloud for how that split of responsibility works.