How does Ingate plan to differentiate itself from other NGINX-based Gateway API implementations?

[devmosaic44]

Hi,

I’m evaluating Gateway API solutions and came across Ingate. I’d love to hear the long-term vision for how Ingate plans to stand out from other NGINX-based Gateway API implementations.

More specifically, what are some key reasons someone might choose Ingate over NGINX Gateway Fabric—beyond differences in product maturity?

[gavinkflam]

Same question.

I think Ingate is meant to be a reference implementation? Moreover, it is helpful for users to transition from Ingress to Gateway API, since it supports both ingresses and gateways?

[strongjz]

First, it will be a community driven project with backing and support from sig-network and Gateway API. We want InGate to be the KinD of Gateway API implementations. InGate should allow users to test their migrations to Gateway API and help their users with the pain of migration. The Ingress API was frozen more that 5 years ago, which means no new features and Ingress-nginx is following suite. Ingress-Nginx is an older project that carries a lot of technical debt, and adding new features via annotation is not a great experience for maintainers and users.

As far as the comparison to NGINX Gateway Fabric and InGate, I would like to think it is the same as Ingress-nginx to NGINX Ingress, choice or Cilium and Isovalent Enterprise. We're not here to be the enterprise choice for Gateway API, if you need that level of support it makes sense to build a team that can manage OSS software like InGate or buy support from a company like F5 and use NGINX Gateway Fabric. Use the tools and level of support that make sense to your use cases.

Leaving Ingress-nginx users with no migration path is irresponsible. Partnering with Gateway API and ingress2gateway, we will have a future set that allows users to make hopefully a seamless migration, and continue to grow the Gateway API itself for all implementations. We have been doing some investigations comparing Gateway API to Ingress-Nginx functionality, 35% of Ingress-Nginx features are supported today and 55% supported soon, with InGate we want to push Gateway API maintainers to support a majority of Ingress-Nginx features in a stable API, not in annotations, regex and strings, which our prone to vulnerabilities.

@robscott and I will be talking more about this at Kubecon London 2025, Making the Leap: What Gateway API Needs To Support Ingress-NGINX Users , and @Gacko and I will be discussing more about the InGate project in How To Gateway With Ingress - 140 Days InGate.

For features, we are asking Ingress-nginx to let us know what is important to them in this survey