NGINX Ingress Controller is primarily used for routing in my team's Kubernetes cluster where we run multiple microservices. We deployed NGINX Ingress Controller on a cluster with around 20 microservices and different endpoints that we wanted to route requests to, so we specified all the paths we wanted to route to in the YAML files. Apart from my current projects, I have also used NGINX Ingress Controller in some open-source deployments where I needed to route requests.
Technical Lead: Cloud Engineering at Fiftytwo Digital Limited
Real User
Top 10
May 24, 2026
My main use case for NGINX Ingress Controller is load balancing as well as an API Gateway to perform reverse proxy for our backend applications. A specific example of how I use it as a load balancer and API Gateway in my environment is that we have our own DNS resolver, which we use ACME with as a free DNS resolving service. We bind it to the Ingress Controller and add our own rules and hosts to specific Ingress resources to bypass and forward all requests to the specific backends. This helps balance the load by making replicas on-demand. Regarding my main use case, we implement custom configurations as well as custom port mappings and annotations. We use specific server snippets and follow security best practices to drop SSL terminations at the Ingress level instead of in the backend.
Senior Network At Dxc Technology Professional at DXC Technology
Real User
Top 5
May 7, 2026
I have worked on NGINX Ingress Controller with an on-premises deployment model. There is an option for cloud as well, and SaaS solutions are also available. The recent project I completed was NGINX Ingress Controller in Google Cloud for one of our clients.
The simplest and most common use case in my country is somebody adopting microservice technology who was using Ingress Controller community edition and wanted to move to enterprise level. Someone wanting to have microservices and containerization applications desired commercial, enterprise-grade Ingress Controller, so they moved to F5 Ingress Controller, which is NGINX Ingress Controller.
My main use case for NGINX Ingress Controller is managing the traffic that comes through our application. If the server is down or if clients are unable to access our app, then we manage NGINX Ingress Controller. We check if the pod is healthy or not and if the traffic is routing properly or not. A specific example of when NGINX Ingress Controller helped me solve a problem is when it routes people accessing our applications. For instance, if users try to access example.com/a, then NGINX Ingress Controller routes them to service A, and if they try to access example.com/b, it sends the traffic to service B.
Information Security Engineer at a outsourcing company with 1,001-5,000 employees
Reseller
Top 20
Mar 12, 2026
I am currently working with NGINX Ingress Controller but in a different perspective than before. We haven't used App Protect anymore, but as an implementer, we use it as a front end for an AI gateway to do some mapping for certain information before sending the LLM request to the AI gateway. NGINX Ingress Controller itself is a reverse proxy, so we manipulate some requests. We utilize NGINX Ingress Controller to manipulate some requests prior to the AI gateway. My use case has changed because nowadays the main focus for use cases are for AI and AI security that mainly focuses on LLM security.
Python Developer and Application Analysts at All Solutions
Real User
Top 20
Jan 4, 2026
My main use case for NGINX Ingress Controller is as a smart traffic controller, with the built-in firewalls, DoS protections for our APIs, and better reliability under load. Whenever we need to manage traffic, we have contact with our tenants, so we create the hostname with their name and define a pod for them, allowing NGINX Ingress Controller to automatically scale the software and increase the number of pods when the number of users for this hostname increases, ensuring we don't lose traffic and the whole site doesn't go down. Additionally, we can use advanced traffic and routing management, plus monitoring tools with their APIs. Whenever a site goes down or any error occurs, we receive instant error notifications through the API, which is really helpful.
NGINX Ingress Controller efficiently manages external access to services in Kubernetes, ensuring secure connection handling and traffic flow. Its robust architecture supports high availability, scalability, and performance, making it a vital component for managing ingress resources.NGINX Ingress Controller serves as a critical ingress point for Kubernetes clusters, offering vast customization options and seamless integration with NGINX and NGINX Plus. It provides enterprises with scalable...
NGINX Ingress Controller is primarily used for routing in my team's Kubernetes cluster where we run multiple microservices. We deployed NGINX Ingress Controller on a cluster with around 20 microservices and different endpoints that we wanted to route requests to, so we specified all the paths we wanted to route to in the YAML files. Apart from my current projects, I have also used NGINX Ingress Controller in some open-source deployments where I needed to route requests.
My main use case for NGINX Ingress Controller is load balancing as well as an API Gateway to perform reverse proxy for our backend applications. A specific example of how I use it as a load balancer and API Gateway in my environment is that we have our own DNS resolver, which we use ACME with as a free DNS resolving service. We bind it to the Ingress Controller and add our own rules and hosts to specific Ingress resources to bypass and forward all requests to the specific backends. This helps balance the load by making replicas on-demand. Regarding my main use case, we implement custom configurations as well as custom port mappings and annotations. We use specific server snippets and follow security best practices to drop SSL terminations at the Ingress level instead of in the backend.
I have worked on NGINX Ingress Controller with an on-premises deployment model. There is an option for cloud as well, and SaaS solutions are also available. The recent project I completed was NGINX Ingress Controller in Google Cloud for one of our clients.
The simplest and most common use case in my country is somebody adopting microservice technology who was using Ingress Controller community edition and wanted to move to enterprise level. Someone wanting to have microservices and containerization applications desired commercial, enterprise-grade Ingress Controller, so they moved to F5 Ingress Controller, which is NGINX Ingress Controller.
My main use case for NGINX Ingress Controller is managing the traffic that comes through our application. If the server is down or if clients are unable to access our app, then we manage NGINX Ingress Controller. We check if the pod is healthy or not and if the traffic is routing properly or not. A specific example of when NGINX Ingress Controller helped me solve a problem is when it routes people accessing our applications. For instance, if users try to access example.com/a, then NGINX Ingress Controller routes them to service A, and if they try to access example.com/b, it sends the traffic to service B.
I am currently working with NGINX Ingress Controller but in a different perspective than before. We haven't used App Protect anymore, but as an implementer, we use it as a front end for an AI gateway to do some mapping for certain information before sending the LLM request to the AI gateway. NGINX Ingress Controller itself is a reverse proxy, so we manipulate some requests. We utilize NGINX Ingress Controller to manipulate some requests prior to the AI gateway. My use case has changed because nowadays the main focus for use cases are for AI and AI security that mainly focuses on LLM security.
My main use case for NGINX Ingress Controller is as a smart traffic controller, with the built-in firewalls, DoS protections for our APIs, and better reliability under load. Whenever we need to manage traffic, we have contact with our tenants, so we create the hostname with their name and define a pod for them, allowing NGINX Ingress Controller to automatically scale the software and increase the number of pods when the number of users for this hostname increases, ensuring we don't lose traffic and the whole site doesn't go down. Additionally, we can use advanced traffic and routing management, plus monitoring tools with their APIs. Whenever a site goes down or any error occurs, we receive instant error notifications through the API, which is really helpful.