ingress nginx EOL.

[abejide...@gmail.com]

Hi Friends,

I just read the blogpost on EOL for ingress-nginx at
https://www.kubernetes.dev/blog/2025/11/12/ingress-nginx-retirement/. It did
come as a bit of surprise that there was no discussion on this mailing list and
that security updates will be discontinued for this widely used project.

I would like to know what I can do to help keep security updates going for
ingress-nginx and if that's not a thing that is possible what can be done to
extend "best-effort" maintenance beyond March 2026 as my organization relies
heavily on this project.

Thanks,

Ayo

[Benjamin Elder]

I believe the blog actually covered all of this rather clearly.

>  It did come as a bit of surprise that there was no discussion on this mailing list and [...]

Until sometime today this was pinned to the top of the issue tracker: https://github.com/kubernetes/ingress-nginx/issues/13002

Additionally, the blog has more details about how the direction for the project was previously communicated in other ways.

> [...] that security updates will be discontinued for this widely used project. 

Unfortunately, widely used does not mean wide participation.
Many organizations depended on the work of a few overworked volunteers.

The Kubernetes project is providing the resources to ensure that there are updates through the announced deadline.

> I would like to know what I can do to help keep security updates going for
ingress-nginx and if that's not a thing that is possible what can be done to
extend "best-effort" maintenance beyond March 2026 as my organization relies
heavily on this project.

The time for that was more than a year ago.

Open source is built on trust, and building trust takes time.
We cannot build the trust to take over a project like this at the last moment.
If organizations were interested in staffing the project long-term, there was ample opportunity to do so previously with plenty of signals about the state of the project.

You could, however, fork it while respecting the open source license and maintain your own patches and builds.

- Ben

--
You received this message because you are subscribed to the Google Groups "kubernetes-sig-network" group.
To unsubscribe from this group and stop receiving emails from it, send an email to kubernetes-sig-ne...@googlegroups.com.
To view this discussion visit https://groups.google.com/d/msgid/kubernetes-sig-network/461a1c97-2daa-43d3-9c98-a4f1c6bba59bn%40googlegroups.com.

[Sandor Szuecs]

I think there’s another obvious option:

Pay the former volunteering maintainers to work on it full time for money. If there are so many companies relying on it, it could be even cheaper for everyone, if they would staff a team of engineers to work on the project.

Sandor Szücs | 418 I'm a teapot

To view this discussion visit https://groups.google.com/d/msgid/kubernetes-sig-network/CAOZRXm9-ULkCVQ8OjcEEfoEOpyjUgv3S1QDgnVrD7WZ2HRppfg%40mail.gmail.com.

[Àbéjídé Àyodélé]

> Until sometime today this was pinned to the top of the issue tracker: https://github.com/kubernetes/ingress-nginx/issues/13002

The number one bullet point on the issue tracker had the below:

* Continued monthly release patches.
* Golang updates
* Alpine updates
* Other 3rd party dependencies
* CVE patches
* Bug fixes

None of that indicated EoL. The expectation was that the project will
continue to get security updates, ingress v1 API has been stable for a
while now so it is a perfectly fine expectation that any ingress
controller today will be considered *done* outside of security
patches.

> You could, however, fork it while respecting the open source license and maintain your own patches and builds.

The advantage a project hosted under kubernetes org gets is that it
has a lot of eyes on it and security researchers can be confident they
are submitting reports to a trusted party. Hosting a fork completely
loses all of that value.

Abejide Ayodele
It always seems impossible until it's done. --Nelson Mandela

[James Strong]

The plan was always to EoL ingress-nginx, the difference here now is that we do not have migration plan to ingate. Life happens and the focus for the maintainers has been life outside open source. 

As far as paying us for it. Its not about money, its time and energy outside OSS software. Neither of us were doing as part of our day job, nor the maintainers before us. 

We will continue to work with sig-network, steering and SRC, to help navigate the migration. 

We had a spreadsheet of features of ingress-nginx to gateway api, we compared that to 1.3, we are going to update it for 1.4. We will continue to have patched release until March.

I guarantee you no one is more disappointed and sadden by this than myself and Marco. 

We gave the project 5 more years when in this mailing list, the initial maintainer stepped down. It is time we as a community embrace and migrate to gateway api. 

Thank you,

James

[Fox, Kevin M]

Is there any interest in a community project/ingress controller that reads in ingress-nginx based ingress objects with some common annotations, and spits out equivalent httpRoutes and envoy gateway specific config to ease the transition? From what we've seen on our clusters based on what annotations are used, that may be possible without a lot of effort.

https://github.com/kubernetes-sigs/ingress2gateway isn't currently a solution, as it doesn't really address existing helm chart deployments. Its a manual, one time kind of thing.

________________________________________
From: 'James Strong' via kubernetes-sig-network <kubernetes-...@googlegroups.com>
Sent: Thursday, November 13, 2025 9:59 AM
To: kubernetes-sig-network
Subject: Re: [k8s-sig-net] ingress nginx EOL.

Check twice before you click! This email originated from outside PNNL.

The plan was always to EoL ingress-nginx, the difference here now is that we do not have migration plan to ingate. Life happens and the focus for the maintainers has been life outside open source.

As far as paying us for it. Its not about money, its time and energy outside OSS software. Neither of us were doing as part of our day job, nor the maintainers before us.

We will continue to work with sig-network, steering and SRC, to help navigate the migration.

We had a spreadsheet of features of ingress-nginx to gateway api, we compared that to 1.3, we are going to update it for 1.4. We will continue to have patched release until March.

I guarantee you no one is more disappointed and sadden by this than myself and Marco.

We gave the project 5 more years when in this mailing list, the initial maintainer stepped down. It is time we as a community embrace and migrate to gateway api.

Thank you,
James

On Thursday, November 13, 2025 at 8:28:27 AM UTC-5 Àbéjídé Àyodélé wrote:

> Until sometime today this was pinned to the top of the issue tracker: https://github.com/kubernetes/ingress-nginx/issues/13002<https://github.com/kubernetes/ingress-nginx/issues/13002>

The number one bullet point on the issue tracker had the below:

* Continued monthly release patches.
* Golang updates
* Alpine updates
* Other 3rd party dependencies
* CVE patches
* Bug fixes

None of that indicated EoL. The expectation was that the project will
continue to get security updates, ingress v1 API has been stable for a
while now so it is a perfectly fine expectation that any ingress
controller today will be considered *done* outside of security
patches.

> You could, however, fork it while respecting the open source license and maintain your own patches and builds.

The advantage a project hosted under kubernetes org gets is that it
has a lot of eyes on it and security researchers can be confident they
are submitting reports to a trusted party. Hosting a fork completely
loses all of that value.

Abejide Ayodele
It always seems impossible until it's done. --Nelson Mandela

On Wed, Nov 12, 2025 at 10:02 PM Benjamin Elder <benth...@google.com> wrote:
>
> I believe the blog actually covered all of this rather clearly.
>
> > It did come as a bit of surprise that there was no discussion on this mailing list and [...]
>

> Until sometime today this was pinned to the top of the issue tracker: https://github.com/kubernetes/ingress-nginx/issues/13002<https://github.com/kubernetes/ingress-nginx/issues/13002>

>
> Additionally, the blog has more details about how the direction for the project was previously communicated in other ways.
>
> > [...] that security updates will be discontinued for this widely used project.
>
> Unfortunately, widely used does not mean wide participation.
> Many organizations depended on the work of a few overworked volunteers.
> The Kubernetes project is providing the resources to ensure that there are updates through the announced deadline.
>
> > I would like to know what I can do to help keep security updates going for
> ingress-nginx and if that's not a thing that is possible what can be done to
> extend "best-effort" maintenance beyond March 2026 as my organization relies
> heavily on this project.
>
> The time for that was more than a year ago.
>
> Open source is built on trust, and building trust takes time.
> We cannot build the trust to take over a project like this at the last moment.
> If organizations were interested in staffing the project long-term, there was ample opportunity to do so previously with plenty of signals about the state of the project.
>
> You could, however, fork it while respecting the open source license and maintain your own patches and builds.
>
> - Ben
>
> On Wed, Nov 12, 2025 at 4:29 PM abejide...@gmail.com <abejide...@gmail.com> wrote:
>>
>> Hi Friends,
>>
>> I just read the blogpost on EOL for ingress-nginx at

>> https://www.kubernetes.dev/blog/2025/11/12/ingress-nginx-retirement/<https://www.kubernetes.dev/blog/2025/11/12/ingress-nginx-retirement/>. It did

>> come as a bit of surprise that there was no discussion on this mailing list and
>> that security updates will be discontinued for this widely used project.
>>
>> I would like to know what I can do to help keep security updates going for
>> ingress-nginx and if that's not a thing that is possible what can be done to
>> extend "best-effort" maintenance beyond March 2026 as my organization relies
>> heavily on this project.
>>
>> Thanks,
>>
>> Ayo
>>
>> --
>> You received this message because you are subscribed to the Google Groups "kubernetes-sig-network" group.
>> To unsubscribe from this group and stop receiving emails from it, send an email to kubernetes-sig-ne...@googlegroups.com.

>> To view this discussion visit https://groups.google.com/d/msgid/kubernetes-sig-network/461a1c97-2daa-43d3-9c98-a4f1c6bba59bn%40googlegroups.com<https://groups.google.com/d/msgid/kubernetes-sig-network/461a1c97-2daa-43d3-9c98-a4f1c6bba59bn%40googlegroups.com>.

--
You received this message because you are subscribed to the Google Groups "kubernetes-sig-network" group.

To unsubscribe from this group and stop receiving emails from it, send an email to kubernetes-sig-ne...@googlegroups.com<mailto:kubernetes-sig-ne...@googlegroups.com>.
To view this discussion visit https://groups.google.com/d/msgid/kubernetes-sig-network/14a821b3-1cfb-4305-b5fb-edec6582eb0dn%40googlegroups.com<https://groups.google.com/d/msgid/kubernetes-sig-network/14a821b3-1cfb-4305-b5fb-edec6582eb0dn%40googlegroups.com?utm_medium=email&utm_source=footer>.

[Paulo Ponciano]

Hello folks,

I think what we should do now is express our sincere gratitude to all the folks who contributed and kept this project breathing for years. Let's move forward by focusing on Gateway API.

Thanks!

- Paulo Ponciano

[Antonio Ojea]

> Is there any interest in a community project/ingress controller that reads in ingress-nginx based

https://github.com/kubernetes-sigs/ingress2gateway seems the natural home for that, why not contribute to that existing subproject?

We already have one controller that does exactly that in https://github.com/kubernetes-sigs/cloud-provider-kind/tree/main/pkg/ingress, just take it as an example and contribute it to https://github.com/kubernetes-sigs/ingress2gateway 

To view this discussion visit https://groups.google.com/d/msgid/kubernetes-sig-network/01c918c2-ba42-4e9a-b2fe-c5ebaef2aa6an%40googlegroups.com.

[Dan Winship]

On 11/13/25 3:32 PM, 'Fox, Kevin M' via kubernetes-sig-network wrote:
> Is there any interest in a community project/ingress controller that reads in ingress-nginx based ingress objects with some common annotations, and spits out equivalent httpRoutes and envoy gateway specific config to ease the transition?

That's essentially what InGate was going to be (except still using nginx
on the gateway side, not envoy). It seems like there's definitely
interest in *having* such a controller, but not enough interest in
actually *implementing* that controller.

> From what we've seen on our clusters based on what annotations are used, that may be possible without a lot of effort.

Yeah, but the annotations you're using aren't necessarily the ones other
people are using... there's presumably *somebody* using every annotation.

> https://github.com/kubernetes-sigs/ingress2gateway isn't currently a solution, as it doesn't really address existing helm chart deployments. Its a manual, one time kind of thing.

While it may not solve your problem directly, you may be better off
trying to leverage the existing work there as part of your solution.

-- Dan