NGINX Ingress Controller Reviews

NGINX Ingress Controller serves as the front door into our Kubernetes clusters that we use for databases. We run a bunch of internal, facing customer APIs and we need something that would do reliable routing without us handling configs and reloading them ourselves. We also lean on it for TCP and UDP load balancing through Transport Server. We have a couple of database-adjacent things like Postgres connection endpoints, a Redis service, and we want to expose them through it rather than standing up separate entities.

The decision to use NGINX Ingress Controller for those database-adjacent services, like the Postgres connection endpoints, is actually a big part of why I care about this working well. Transport Server is what we use to expose data services that are not HTTP. We have Postgres read-replica endpoints and Redis cache that we front through Transport Server for load balancing and TCP load balancing. The thing I always keep in mind is the connection draining and long-lived connections. Databases do not behave the same way as when you have a stateless server like stateless HTTP. A web request is done in fifty milliseconds; a Postgres connection might be open for hours. For example, MySQL has about eight hours for connections to be open until the engine kills them.

My main use case with NGINX Ingress Controller is focused on the connection side, where most of my scar tissue with this thing is. The core NGINX Ingress is fundamentally built around the HTTP request-response model. For connection pooling placements, I never let NGINX Ingress Controller manage database connection concurrency. We do have other connection poolers and load balancing. NGINX Ingress Controller is not a connection pooler; it does not understand the database protocol, transaction boundaries, prepared statements, or any of those sorts of things that a connection pooler manages. So in front of Postgres, we always run pgBouncer between the app and the database. The ingress is just doing some TCP load balancing to get to the pooler or the right replica. I think the mistake people make is thinking the ingress can take the place of a pooler, which it really cannot. It can, but it will just pass through every connection, and you will exhaust the max connections of the DB, even if you have set it to ten thousand.

The best feature that NGINX Ingress Controller offers for my use case is the Transport Server CRD and the dynamic reconfiguration offered with NGINX Plus. This is the number one feature by a wide margin for me. On Plus, endpoint changes update the upstream through the API without a config reload. For anything fronting a database or a connection pooler, this is the difference between rock-solid, long-lived connections and mysterious resets that you have every time a pod reschedules. Another thing is the policy CRD, rate limiting, and access control. This acts as protection for the data tier. You can put a rate limit at the ingress, so one misbehaving client cannot stampede a service and blow up the connection count, just trying to keep things managed and optimal.

This shift away from manual config management has made my team's productivity and efficiency much easier. There was real improvement, but I will be specific about where the speed came from because it is not where people usually assume. Before, exposing a new service or changing a route meant human editing NGINX config, getting it reviewed by whoever owned the edge, and a careful reload during a safe window. That was a ticket and wait process, realistically a day or more of latency for something trivial because it is queued behind whoever owned the config. For databases and data services, it is slower to stand up. Exposing a new Postgres endpoint or a pooler through Transport Server is not just a merge-it thing. It is deliberately so. It involves proxy protocol being wired end-to-end so we keep client attribution. Timeout settings are tuned way up so idle pooled connections do not get ripped. Health check semantics that actually mean something for a database rather than just a TCP connection, and capacity-wise, considering connection counts hitting max connection, it is just more complex with more things involved. The honest summary is that deployment of routing changes got much faster, mostly by removing the human bottleneck rather than any technical speed-up. Deployment of database exposure intentionally did not get faster, and should not, but it got reproducible, reviewable, and instantly revertible. So when you make them, you are able to take them back. For the data tier, the reliability gain mattered far more than raw speed ever would have.

NGINX Ingress Controller can be improved, and my team's concern would be database protocol-aware health checks for Transport Server since that is what NGINX is more focused on. Right now, even on Plus, a Transport Server health check is essentially a TCP connect or maybe a basic send-expect. For a database, that is a weak signal. The listener being up tells you almost nothing about whether Postgres is actually serving, whether a replica is lagging, or whether it is in recovery. I would love a way to define a health check that does something protocol-aware, even something as simple as you open a connection, run a SELECT one, which is the most popular test, and expect a row for Postgres or a PING for Redis. Without that, I am relying on the database's own infrastructure to pull bad replicas, and the ingress will happily continue routing to a replica that answers TCP but is serving stale reads. Better idle connection management for long-lived stream connections can also be improved. A pooled database connection sitting idle between transactions is healthy in my opinion, but the proxy's instinct is to reap idle connections. You can crank timeouts way up, but that is a blunt instrument.

I would like to add that specifically for databases, the need for improvement becomes clearer. Every client connection through NGINX becomes a backend connection, one-to-one. A client connection through NGINX and a client connection through a connection pooler are sitting because they are going to get sent to the backend connection. It does not multiplex; it does not understand transaction boundaries. It cannot reuse a connection across clients. If you put it in front of Postgres without a real pooler behind it, you have just built a very efficient way to exhaust the max connection. The architecture is always client, ingress, connection pooler which is either pgBouncer or ProxySQL, then the actual engine which is Postgres or MySQL. Never let it be clients straight to the database. NGINX Ingress Controller's mode is one client connection to one backend connection with no multiplexing and no protocol awareness, which would be an issue for you.

I have been using NGINX Ingress Controller for three years now.

NGINX Ingress Controller is stable, and I would say there are different stability stories when talking about how it behaves in front of databases. NGINX Ingress Controller is stable itself. NGINX's data plane is rock solid. I do not really experience any reliability issues.

For scalability, HTTP scales very well horizontally. It is straightforward. More controller pods behind the LB, and NGINX handles higher requests and connection volumes per pod efficiently. It scales really well.

For NGINX Ingress Controller's customer support, I experience community support for the open-source side which means GitHub issues, project documentation, Slack, and community channels. On NGINX Plus side, there is paid commercial support. They are obviously available to help with issues that I have, and I have encountered great engineers. Overall, it is a great experience.

I have seen a return on investment, but I do not have the actual numbers. The return is an avoided cost story, not a revenue or savings line. The clearest return is incidents that stopped happening. We used to have multiple incidents, but they stopped happening before we moved data tier parts to NGINX Plus. We had a recurring category of incidents. I would not say fewer employees; I would push back on that being the sense of it. NGINX Ingress Controller's ROI is real, but that is all I have to say, to be honest.

I do not have much to say on the pricing, setup cost, and licensing front. There is a different functional team for managing costs and licensing in the environment. I can say a few things from my experience, though. The core dynamics and core features for databases involve the paywall. The paywall is what concerns me. I am not really sure about every other cost, but the decision lies with the other functional team.

Before NGINX Ingress Controller, we came off community ingress NGINX, and before that, plain HAProxy managed by hand for the database parts. We evaluated a few solutions such as HAProxy, ingress, Traefik, and Envoy. The decision came down to CRD-based config ownership plus a paid escape hatch for the reload problem on the database parts. This is purely a review based on its interaction with databases. The platform engineering team uses NGINX Ingress Controller for various important aspects of covering all of the tech platform and services that we manage.

My advice for others looking into using NGINX Ingress Controller, especially for the database side of things, is to be aware that the ingress is deliberately a stateless system. Every problem you will have comes from forgetting something. Internalize that the ingress does not understand the database. Never let it act as a connection pooler. Always put a real pooler behind it. The architecture is always client, ingress, your connection pooler which is either pgBouncer or ProxySQL, then your actual engine which is Postgres or MySQL. Never let it be clients straight to the database. NGINX Ingress Controller's mode is one client connection to one backend connection with no multiplexing and no protocol awareness, which would be a major issue for you. I have given this product a rating of seven out of ten.

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.

I have utilized NGINX Ingress Controller SSL and TLS termination feature. We have done extensive SSL offloading on NGINX Ingress Controller and made the TLS configurations to match security requirements, allowing certain TLS versions while disabling others such as 1.0, 1.1, and 1.2, and allowing 1.3. The choice depends upon the application requirement.

The reverse proxy capabilities of NGINX Ingress Controller in managing distributed applications is central to its main concept. We need to configure it to allow the server to access the outside world and the internet. That is achievable, and we can install and configure NGINX Ingress Controller as a reverse proxy. It can work as a load balancer, but the main part is NGINX Ingress Controller's role as a reverse proxy. If any applications need to be accessed through the proxy to the outside world, then NGINX Ingress Controller is a good product for you.

I employ the IP whitelisting feature in NGINX Ingress Controller, which helps secure my application environment. In IP whitelisting, there are several options available. You can determine which IPs to block, for example, if you do not want to give access to specific regions. You can find the list of IP addresses registered in those regions and blacklist them. There is also the web application firewall (WAF) where you can create policies to identify the type of traffic trying to access the application.

I have not integrated NGINX Ingress Controller with solutions such as Prometheus or Grafana. We have not received any projects of that nature yet.

Integrating capabilities with third-party tools are mostly about monitoring or sending logs. Working with the upper layer, such as upper layer firewalls, depends on what kind of integration you are looking for.

I have worked with NGINX Ingress Controller for only a couple of years, and I recently started working on it. I do not have extensive experience with it, but with other F5 products, I have more than fifteen to twenty years of experience.

I have not seen any issues integrating NGINX Ingress Controller with other security products, such as firewalls. We have implemented it in AWS, using NLB and the AWS product firewall. For the WAF, we have used Akamai products. For WAF solutions, we have integrated with NLB on the AWS side and the internal AWS firewalls. Sending logs and integrating with firewalls has not presented any issues. It may depend on the kind of software; sometimes older software may not integrate properly, and we might need upgrades or patching. Normally, when issues arise, I reach out to the vendor; they provide patches to fix those issues. After that, I upgrade the software, and the issues usually go away.

Implementing NGINX Ingress Controller and installing the instance requires a few hours. After that, depending on what applications you are going to deploy and how many applications you are going to deploy, it might take time. If you are going to deploy one hundred or two hundred applications, then it is going to take a considerable amount of time. If you have only a few applications, such as five or ten, or you are planning for only a single application, then it is not going to take much time. So, within a day, you can bring up the devices and make them active.

My experience with F5's technical support was excellent around ten years ago, with very good response rates. Nowadays, the quality has been degrading, and I do not expect the same level of service. While they have improved their ticketing system, allowing online submissions and status checks, the skill levels of the technical staff seem to have reduced. That is what I am observing day by day, as I have worked with many highly skilled professionals in the past, and I notice a difference now.

I would rate their technical support somewhere around a three on a scale of one to ten.

The deployment process of NGINX Ingress Controller is not complex, I would say, because as a network engineer, I may not be able to know all those HTML coding aspects. That is a challenge I faced, because the coding part is new for me. I need to learn and do it. Other than that, I have not seen any other challenges. It is similar to a normal server installation; after that, you need to do the configurations such as network configuration to make the system available in the network. Then, you can implement the load balancer concept, such as installing web in the backend servers. If there is any SSL offloading, that may be the challenging part I faced.

There are a couple of options available for purchasing NGINX Ingress Controller. You can buy your own license, or you can use it based on the usage. It is similar to AWS coming up with their own license, and based on the usage, they will charge you. Another option is to buy a license directly from F5 or a vendor, which is a bring your own license (BYOL) option, and use that license to install it on the AWS Marketplace. You can install your instance, use this instance, and make use of that. Several options are available.

Regarding licensing costs for NGINX Ingress Controller, if you are talking about costs, F5 is always very costly. The license is very costly compared to other vendors such as VMware or AWS inside load balancer or other Akamai load balancers. However, the response, throughput, and solid performance we receive after implementation are often worth it. Most of the time, I have not seen any issues, and the systems run very smoothly. This is just my experience, and opinions may vary per person. I have not encountered significant issues; the feedback from end users and clients has been very positive.

NGINX Ingress Controller is functional, but it is achievable and may take some extra time. The major issues typically relate to vulnerabilities, which F5 addresses with patches that require timely software upgrades to mitigate. I would rate this review a nine overall.

My main use case for NGINX Ingress Controller involved a banking application that was a cluster of Kubernetes where they wanted to monitor if the ingress controller could act as a load balancer.

I set it up for their banking application by initially working with the community edition of NGINX Ingress Controller. We then proposed NGINX Plus to them, which is now acquired by F5.

The best features that NGINX Ingress Controller offers in my experience are that the ingress controller can perform content-based routing and SSL termination, which is usually not available on software-only solutions and typically comes with hardware-based solutions.

Content-based routing and SSL termination have helped our customers significantly. For example, one customer, a bank, needed to utilize their own GPT which had two instances, one on the cloud and one on-premises. They had to route between the on-premises and cloud instances, which we could not have accomplished without the ingress controller.

NGINX Ingress Controller has positively impacted my organization and my customers because, since F5 acquired NGINX, the support is quite responsive. When you contact them, they immediately respond to the problems we have.

A specific example is that we usually open cases based on priority, and when we set a priority for a site down, the engineer came within approximately fifteen minutes. This response time was excellent.

NGINX Ingress Controller itself is a great product, but when considering a complete solution, there are limitations. NGINX Ingress Controller does not provide the security and web application security features that come with full application delivery controllers, such as WAF and AWAF.

NGINX Ingress Controller can be improved in terms of security and WAF features, but it should remain lightweight as it is currently. This lightweight characteristic is a very significant advantage that prevents any overheads on the systems running the applications.

Additionally, there should be a dashboard for NGINX that shows all the metrics and monitoring information. For example, monitoring solutions such as DataDog have one pod in the entire environment that takes all information from all other pods and displays it on a dashboard. If there were an NGINX pod that could monitor the applications as well, it would be a great addition.

I have used it for some customers who were already using it while they were on Kubernetes environments with containerized applications. They wanted to deploy F5 as a load balancer for the Kubernetes environments. We proposed NGINX Ingress Controller for their Kubernetes environments and F5 as a load balancer for their monolithic applications.

In my experience, NGINX Ingress Controller is quite reliable and I have not faced any downtime or reliability issues.

NGINX Ingress Controller's scalability is excellent. The scaling of containerized environments became really easy when we use NGINX Ingress Controller. Before that, it was really difficult to maintain all the scaling up and scaling down manually. We had to manually determine if the number of users increased to a specific limit, then scale up to more pods, and if concurrent sessions reduced, then reduce the pods. However, with the ingress controller, we can do this automatically.

Customer support for NGINX Ingress Controller is great. When I reported that there was a connection mismatch between a customer's existing environment and their DR, the technician came within fifteen minutes. This response was excellent.

I previously used the default ingress controller for Kubernetes before switching to NGINX Ingress Controller. This switch helped me because the configuration is really easy on NGINX compared to other software.

I have seen a return on investment with NGINX Ingress Controller because most organizations, especially small organizations or SMBs, don't buy a specific load balancer, such as F5 load balancer or Fortinet ADC. They go with a software-based load balancing solution. This represents a huge cost-cutting opportunity for them. Since the acquisition by F5, having support on NGINX is really great. Even the organizations that need to ensure they have support can take NGINX Ingress Controller as their go-to solution.

My experience with pricing, setup cost, and licensing for NGINX Ingress Controller is that we discussed the pricing with our distributor in Pakistan, which is Awan Distribution. The setup cost does not involve any capital expenditure. It is basically a license through a subscription model. The subscription renews regularly. I believe this is a better licensing model rather than selling the product once and then doing a subscription for services. It is better to go with subscription-based models.

Before choosing NGINX Ingress Controller, I considered evaluating other options such as HAProxy. The configuration on HAProxy was really cumbersome and HAProxy also did not have any support. NGINX was my best option.

I suggest that it would be great if we could integrate NGINX Ingress Controller with F5 so we can see all the pods and all the applications running in the cluster environments or containerized environments on the F5 interface.

I would rate NGINX Ingress Controller as an eight on a scale of one to ten. The reason I give it an eight instead of a higher or lower score is that since the acquisition by F5, the prices of NGINX Plus have increased drastically, which is a downside. However, I gave a good number, more than five, because NGINX usually comes up to the mark when we talk about application load balancing and communication between containers. If a container dies and comes up again with a new IP, then NGINX Ingress Controller automatically routes the traffic to it instead of sending the traffic to the wrong container that is no longer present.

My advice for others looking into using NGINX Ingress Controller is that if they are deploying it in their production environment, they should take the support from F5 for NGINX Plus because without the support, they are really stuck. If they get a problem and cannot resolve it, they have to take downtimes. My overall rating for this product is eight out of ten.

My main use case for NGINX Ingress Controller has been in Kubernetes-based consulting work, especially when a team needs a controlled and observable entry point for application traffic.

In a typical setup, a user or client application sends a request to a public endpoint. That request first reaches an external load balancer, depending on the environment — for example, a cloud load balancer, MetalLB in a lab or bare-metal setup, or another external load-balancing layer. From there, the traffic is forwarded to the NGINX Ingress Controller running inside the Kubernetes cluster.

That is where NGINX Ingress Controller becomes important. It evaluates the Kubernetes Ingress rules, applies routing decisions based on hostnames and paths, and forwards the request to the right Kubernetes Service. The Service then sends the traffic to the correct backend pods, such as web pods, API pods, or authentication pods.

What I value most is that NGINX Ingress Controller is not just a way to expose services. It gives teams a practical control point for TLS termination, HTTP routing, rewrites, annotations, timeouts, security headers, rate limits, and observability. But it needs to be operated carefully. In production, the biggest risk is usually not NGINX itself, but weak configuration, missing monitoring, unclear ownership, or unsafe upgrades.

NGINX Ingress Controller helped by giving teams a predictable entry point for Kubernetes workloads. Instead of exposing services one by one, traffic could be routed through a controlled layer for TLS, host/path routing, rewrites, headers, logs, and metrics. The main benefit was operational clarity: better visibility, safer exposure of services, and fewer ad hoc networking decisions.

The best features are Kubernetes-native routing, TLS termination, flexible host/path rules, annotations, ConfigMaps, and observability when metrics and logs are configured well. In practice, it turns ingress into a clear control point for HTTP/HTTPS traffic. The trade-off is governance: annotations, rate limits, certificates, and upgrades need discipline.

I would improve diagnostics and guardrails. A built-in support bundle command that safely collects controller config, events, logs, versions, certificate status, and redacted error data would help teams troubleshoot faster. I would also like stronger policy controls around risky annotations, rate limits, TLS expiry, and upgrade validation. It should help security, but not pretend to replace Zero Trust or vulnerability management.

I have been using NGINX Ingress Controller for more than two years.

I consider it stable when deployed with disciplined configuration. In my experience, the controller itself is not usually the weak point. Problems tend to come from unclear annotations, certificate issues, poor observability, under-sized resources, or upgrades without staging. With good operational practices, it is reliable.

Scalability is strong because it fits naturally into Kubernetes. You can run multiple controller replicas, use resource requests/limits, autoscaling, and a load balancer in front of it. The important point is to test the whole path: controller capacity, backend services, TLS, rate limits, observability, and failure behavior under load.

My experience with support was mostly community/self-managed. In the environments I worked with, the client did not use NGINX Plus or premium support, so issues were handled through internal expertise, documentation, and consulting help when needed. For mission-critical production use, I would consider paid support or a supported controller path.

Yes. Before using NGINX Ingress Controller, I worked with more traditional network controls such as Layer 3 firewalls and manual routing rules. They were useful, but not enough for cloud-native workloads because Kubernetes needs application-aware routing by host, path, TLS, and service. That gap pushed me toward an ingress controller.

The initial setup is usually straightforward for a basic lab or small environment, but production setup is more complex. Installing the controller is not the hard part. The real work is DNS, TLS, load balancer integration, annotations, observability, resource sizing, security headers, staging, and upgrade/rollback discipline.

In the implementations I worked with, I did not rely on a dedicated integrator or reseller. The solution was deployed as part of the Kubernetes environment, and in one context it was obtained through AWS Marketplace. Most of the value came from internal/consulting implementation discipline rather than from a third-party integrator.

Yes. The ROI comes from reducing networking complexity and improving the safety of exposing Kubernetes services. Instead of handling every service separately, teams get a consistent ingress layer for TLS, routing, headers, logs, and metrics. The value is strongest when it prevents downtime, misrouting, expired certificates, or insecure exposure.

My experience was positive because the implementation I worked with was deployed as part of the Kubernetes stack, without premium NGINX support. That made the initial cost low. The real cost is operational: proper configuration, monitoring, certificate management, testing, upgrades, and people who understand Kubernetes ingress behavior.

I considered lower-level approaches such as iptables and traditional firewall/load-balancer rules. They can work, but they become hard to maintain as the number of services grows. NGINX Ingress Controller is easier to operate in Kubernetes because routing lives closer to the application model. The trade-off is that annotations and controller configuration must be governed carefully.

I would rate it 9/10 when it is operated intentionally. My advice is not to treat it as just a YAML shortcut. Use it with clear ownership, staging, controlled annotations, TLS monitoring, logs, metrics, resource limits, and rollback plans. For new designs or long-term roadmaps, also evaluate Gateway API or a supported controller path.

NGINX Ingress Controller serves our organization primarily for routing, SSL/TLS termination, and load balancing.

A specific example of how I used NGINX Ingress Controller for routing is that we define the paths and the applications inside the NGINX.conf. The traffic routes to the services, and we set up the load balancing at their own configurations level. Apart from that, we see limitations in NGINX Ingress Controller, as we have multiple services. We need to define the configurations in the annotation section, which causes a mess. Regarding SSL/TLS termination, since the traffic comes from outside to inside, the load balancer reads it out and redirects it to NGINX. We terminate that traffic at the NGINX configuration and then redirect the traffic to the services and ports without SSL/TLS. We used it for a long time before we shifted towards ALB for the last six months.

In my use case with NGINX Ingress Controller, when we have multiple services, it becomes messy and overburdened to add the annotations to define the policy and the annotations of each service, making it a bit complex. It is not straightforward. NGINX documentation is friendly and very handy, but with a large cluster, as we have a company running around 70 plus services, it is very difficult for us to manage these things.

NGINX Ingress Controller offers several best features, including SSL/TLS and flexible routing, which are the most powerful features. In the Ingress we define path-based routing, and we can define host-based routing; in NGINX, we can also define path-based routing and redirect to service level. The same applies to host-based routing in NGINX. The canary deployments feature allows us to shift a specific amount or percentage toward the new version when a new version is released. These are the very best features that I value in NGINX Ingress Controller.

My experience using canary deployments with NGINX Ingress Controller worked really well, by simply adding canary annotations in the NGINX sections, such as nginx.ingress.kubernetes.io/canary. When we define those annotations in the NGINX configurations, it works well. By adding those, we are able to route a specific percentage of traffic toward the new versions while keeping the remaining percentage on the stable version. This gives us confidence to release the new version without risking the entire user base. The setup is straightforward, though we had to manually monitor the canary traffic since there are no built-in analytics.

NGINX Ingress Controller has positively impacted our organization by efficiently routing the traffic. Previously, we were planning to move toward Traefik, but we see that NGINX is a widely used open-source controller that is easy to deploy in Kubernetes. NGINX documentation is very friendly, making traffic management easy. Managing load balancing configurations does not require significant effort, and deployments are smoother and faster. Managing SSL certificates is also simple. I think it has significantly impacted our organization.

NGINX Ingress Controller can be improved in multiple ways according to my suggestions. First, it takes time when we have many services, making routing complex. It is very difficult to manage the configurations using annotations, as we need to define the annotations of each service separately. A small mistake can break the whole routing policies and structure, making it challenging to debug deployments at large scale, which takes time. I also suggest integrating with Prometheus and Grafana for better visibility into traffic and performance. Overall, pairing NGINX with proper monitoring and GitOps practices makes it much more powerful and manageable.

From a security perspective, we can implement a WAF. That might work to tune the processes. For automation, adopting GitOps strategies instead of manual configurations can mitigate risks. These are improvements that can be added.

In my experience, NGINX Ingress Controller is very reliable and stable. It is very handy during our tenure with NGINX Ingress Controller, and it manages things easily. However, as I mentioned, with a very large cluster, it is challenging to spend time on adding and managing configurations. These are what I suggest could be improved in NGINX Ingress Controller, especially considering it is deprecated in March 2026.

I have been using NGINX Ingress Controller since I started my working profession when I used Ingress Controller in a Texan company, and then in this company, we are using Kubernetes. We deploy our applications on Kubernetes, and at that time we were using Ingress Controller for a long time. Then we decided that we should go with the ALB because we heard news that NGINX Ingress Controller is now deprecated and is going to be deprecated. We used it for one to two years.

NGINX Ingress Controller scalability is excellent. It is highly available and scalable, designed to manage high traffic in Kubernetes. The features include horizontal scaling, so we can scale the controllers by increasing the number of replicas in our deployments. It handles traffic effectively. Since my organization has a large cluster, we utilized this feature. The optimization is good, with a build on NGINX web binaries leveraging an asynchronous event-driven architecture that handles thousands of concurrent connections. The load balancing algorithm is supportive, with options such as round robin and least connections to distribute incoming traffic effectively across backend services.

Regarding customer support for NGINX Ingress Controller, I do not think we had a chance to sync with them. Given its high performance and dynamic reconfigurations, we handle it by our own expertise. We are using the community edition, which is open source, so support is primarily self-service via GitHub issues, Stack Overflow, or the Kubernetes Slack community. We did not get an opportunity to connect with customer support.

From my experience, if someone is a startup and does not want to spend money, I definitely recommend NGINX as a best option. For medium-tier companies also planning to implement an ingress controller, I think NGINX is the best for that. For enterprises seeking a cost-effective solution, NGINX is excellent in that case. The configurations, routing policies, and load balancing management are straightforward, so I highly recommend using NGINX. Additionally, since it has more features, we can implement management tools that do not require manually managing DNS records or SSL certificates. Fine-tuning performance is very good, as NGINX is fast, and the keep-alive feature reduces the overhead of TCP and TLS handshakes. Always set CPU and memory requests for your ingress to reduce throttling or OOM kills during traffic spikes. These are the recommendations I have.

It has been a great experience with NGINX Ingress Controller, and I am definitely looking forward to its return with new features and possibly a new name. We will certainly work with them. I would rate my overall experience with this product as an 8 out of 10.

I use NGINX Ingress Controller for reverse proxy, forwarding client requests while placing it in front of my backend servers. This removes my app from direct internet exposure. I also use it for load balancers to distribute incoming traffic across multiple backend instances using various strategies, which improves availability and throughput.

For example, we run multiple backend services in Docker containers, each running on different internal ports. Instead of exposing each service directly, I place NGINX Ingress Controller in front as a reverse proxy. It handles my SSL termination by managing HTTPS at the NGINX layer using a Let's Encrypt certificate, so the backend containers only speak plain HTTP internally. This simplified the app code and centralized certificate management in one place. It also helps with routing by path, allowing a single domain to route to different services based on path prefix. Without NGINX Ingress Controller, I would have had to separate the domains or expose my ports to the outside. Additionally, it has helped with stability under load.

Since I work with Kubernetes, NGINX Ingress Controller is a natural extension of what the standalone version does. Instead of writing the config manually, I define Ingress resources in YAML files, and the controller reconciles them into NGINX config automatically. The same concepts apply: reverse proxying, path-based routing, and SSL termination. However, it is now managed declaratively and integrates with Kubernetes' native tooling.

I remember one instance when we had a Python Flask inference endpoint running behind NGINX Ingress Controller on Kubernetes. The service processed documents and returned structured data, with some requests taking thirty to sixty seconds depending on document size. The problem we faced was users were intermittently getting gateway timeout errors. The Flask service logs showed the request completing successfully, but clients were still getting the error before the response came back. We diagnosed it by pulling the NGINX Ingress Prometheus metrics into Grafana and filtering by upstream response time per Ingress. This showed clearly that requests beyond sixty seconds were being dropped. The default proxy read timeout on NGINX Ingress Controller is sixty seconds, and nobody had changed it. The app was fine, but NGINX was cutting the connection first. The fix was one annotation on the Ingress resource to increase the timeout. We did not change anything on the app, no redeployment, and no global config map modifications. The timeout was scoped only to that specific Ingress. This resulted in zero timeouts from that endpoint. Since the fix was annotation-based, it did not affect any other services' timeout behavior in the cluster.

The path and host-based routing that NGINX Ingress Controller offers allows me to route traffic to different backend services based on URL path or hostname. There is SSL/TLS termination, which handles HTTPS at the Ingress layer. I pair it with cert-manager and Let's Encrypt for fully automated certificate provisioning and renewal with zero manual certificate management. There are annotations for fine-grained control, which allows me to customize behavior per Ingress without touching global config. Additionally, there is rate limiting, authentication, WebSocket support, and observability. NGINX Ingress Controller exposes Prometheus metrics out of the box.

In many ways, NGINX Ingress Controller has provided cost reduction by eliminating our per-service load balancers. Instead of each service having their own load balancer, we consolidated them behind NGINX Ingress Controller. There are faster deployments, as routing changes previously required infrastructure-level changes, updating DNS, and provisioning new load balancers. With NGINX Ingress Controller, we can apply all these changes in YAML files and reduce the deployment time drastically. There is centralized SSL management, which helped us centralize our certificate provisioning and renewal. Additionally, there is improved reliability with better observability across our services.

There is annotation overload. We could move toward a better API annotation work, though currently the annotations are stringy-typed YAML with no validation, making it easy to create typos. Better error feedback is needed, as when an annotation is wrong or unsupported, the controller often ignores it with no clear error surfaced back to the engineer. Observability depth should be increased. Performance at very high scale should be improved. At extreme scale with hundreds of Ingress resources, the controller can experience reload latency.

Three specific things stand out. The reload problem is architectural, not fixable with a config tweak. The annotation model has no safety net, so if I type an annotation incorrectly, the controller silently ignores it. Configuration snippets are effectively disabled in serious multi-tenant clusters, as those are among the first things security-conscious platform teams turn off.

I have been using NGINX Ingress Controller for over a year.

NGINX Ingress Controller is stable.

NGINX Ingress Controller scales well in horizontal pod autoscaling. The controller itself scales horizontally, and you can run multiple replicas behind the cloud load balancer. There is solid connection handling.

I have had a pretty good experience with customer service. They respond when I reach out and help resolve whatever support issues we have.

I evaluated three main alternatives before settling on NGINX Ingress Controller: Traefik Ingress Controller, the AWS ELB Ingress Controller, and Istio Ingress Gateway.

The initial setup was very fair with no major complications and no overcharging.

The implementation was handled through a vendor relationship only.

For direct cost savings, after consolidating our services behind NGINX Ingress Controller, we were previously spending approximately twelve hundred dollars per year but have significantly reduced those costs.

Each service was previously using its own cloud load balancer. After consolidating every service behind NGINX Ingress Controller, this actually cut down our costs significantly.

I would give NGINX Ingress Controller a rating of six. I recommend starting with the community version. My overall review rating for this product is eight.

NGINX Ingress Controller is my primary solution for managing traffic requests to my Kubernetes workloads. Most of my projects are based on containerization, meaning the applications are completely built on Kubernetes and require traffic routing from the external world to my Kubernetes infrastructure.

I worked on a project with more than 200 microservices where we needed a single entry point solution into the Kubernetes cluster. I deployed one NGINX Ingress Controller and configured HTTP routes for multiple domains through which clients can browse the application. We also implemented some internal private NGINX Ingress Controller instances where internal applications communicate with each other based on domain names. NGINX Ingress Controller allowed us to set up path-based routing and traffic splitting.

In another interesting use case, we had multiple GCP projects and used NGINX Ingress Controller as a single source of truth. We deployed a cluster in one common project with NGINX Ingress Controller and navigated requests to other Kubernetes clusters. All Kubernetes clusters were connected through a mesh called Anthos.

NGINX Ingress Controller offers several valuable features. Unlike other native ingress solutions, we get only one load balancer in the background, which means no matter how many ingresses we create, we receive only one IP address. This significantly saves costs. Additionally, we get all the native NGINX features in NGINX Ingress Controller, including proxy functionality, upstream configuration, rate limiting, header passing, and header control capabilities. These are features that other ingress solutions do not provide to the same extent.

The cost-saving feature of NGINX Ingress Controller is excellent, and the rate-limiting and header control features work very well together. I use these three combinations frequently as they help me control costs and manage headers. Rate limiting also helps secure NGINX Ingress Controller by preventing DDoS and phishing attacks.

Cost was significantly reduced compared to launching another load balancer. We configured NGINX Ingress Controller to work as a gateway. When something breaks, we have a single point of truth for troubleshooting instead of investigating different load balancer stacks. These improvements helped my team troubleshoot issues more efficiently. The time to solve an issue was reduced from thirty to forty minutes to ten to twelve minutes. NGINX Ingress Controller is lightweight, which enhances performance and reduces network request latency.

Some ingress controllers are becoming outdated, and if the features that gateways offer nowadays could be integrated into NGINX Ingress Controller, it would be greatly beneficial.

The main feature I want to see included is the ability to reduce namespace specifications. Currently, gateways are not namespace-specific in Kubernetes, whereas ingresses are namespace-specific. If these namespace specifications could be reduced, it would be a great addition.

I have been using NGINX Ingress Controller for quite a long time because it is an ingress-based solution that works on top of Kubernetes.

NGINX Ingress Controller is stable in my experience. I have not faced many issues with NGINX Ingress Controller so far.

NGINX Ingress Controller is scalable because it is deployed in the form of pods. When additional traffic arrives and NGINX Ingress Controller cannot handle it, it scales based on CPU and memory percentage.

I have not experienced significant issues requiring customer service. When issues do arise, we go through the Marketplace and receive resolutions via email. Since we have not faced substantial issues, the customer service experience has been good.

We were using native cloud solutions and ingresses. We also used other ingresses such as Kong. We compared other ingress solutions in the market including Kong, Apigee, and cloud-native ingresses.

NGINX Ingress Controller is a truly good tool that has proven its capability in the market. I advise others who are looking for solutions to seriously consider NGINX Ingress Controller.

Concerning AI governance and security, there should be proper guardrails around AI capabilities so that I know what components NGINX Ingress Controller is accessing and what things are involved. I am more concerned about the guardrails surrounding NGINX AI Controller capabilities.

Those AI capabilities are reliable because they are AI-based and would be faster than humans. However, I am more concerned about accuracy because all AI capabilities, including NGINX AI capabilities, are based on data. I am aligned with the idea that these are reliable, but sometimes they may produce false positives. This is the main thing that concerns me.

I gave NGINX Ingress Controller a rating of 8 out of 10.

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.

The best features NGINX Ingress Controller offers for my team include all of the commonly available features in the community version. The community version is now obsolete, and Kubernetes wants to move users to something else like the API Gateway feature, but we are still using NGINX Ingress Controller. The features are excellent.

While the features are exceptional, ease of use is not as straightforward because certain configurations probably require the paid version. We are using the free version, and in some cases, features like DNS Route 53 are not available in the free version, so we have to address that use case with alternative solutions.

NGINX Ingress Controller has positively impacted my organization by allowing us to handle many requests from different applications and customers, serving as the frontier of all our backend applications. It performs very well and is both scalable and lightweight. It integrates easily with Kubernetes, so it can be configured and used effectively.

NGINX Ingress Controller can be improved with better documentation. Good documentation in the Bitnami Helm chart would have made implementation easier for us, as we had to search for many things back and forth. Most of the information we found was confused with the community version of NGINX Controller, which created confusion initially. I would appreciate an AI-based solution so that we could easily find the actual use case relevant to our situation.

I have been using NGINX Ingress Controller for five years.

In my experience, NGINX Ingress Controller is stable.

Scalability and lightweight design have helped my team greatly. We recently had issues when multiple backend applications were accessed simultaneously from the same client browser, which caused slowdowns after a certain number of requests, around four or five of the same backend application or different backend applications from the same client. We configured this using a custom annotation configuration with HTTP/2, which solved the overall slow performance easily. NGINX Ingress Controller scales well and is very lightweight. The product manager appreciated the solution because it requires just a simple configuration in the Ingress resource, so no backend application changes are needed. NGINX Ingress Controller scales effectively to support whole load balancing scenarios, routing everything to the specific backend services.

I have not previously used a different solution before NGINX Ingress Controller. Plain NGINX was my first experience, and we stick with it because it serves all our purposes.

I have seen a return on investment from using NGINX Ingress Controller, as I need fewer employees. I do not have to maintain a large DevOps team for this purpose. Any developer can set up and configure NGINX Ingress Controller if they have adequate knowledge on how to set up an Ingress Controller. It saves time because it is easier to set up, though I am uncertain how it translates to monetary savings.

My advice to others looking into using NGINX Ingress Controller is to review the documentation first and ensure it serves your purpose. On a scale of one to ten, I rate NGINX Ingress Controller overall as a nine. I chose nine because I do not know the complete use case of the product, so I do not give it a perfect ten. That is my opinion, and while I have encountered some problems and hurdles, I have overcome all of them. It has worked very well for my purposes.

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.

The performance and stability are what I like about NGINX Ingress Controller. The more important concern is that it can apply App Protect and DDoS protection within NGINX Ingress Controller Plus. Security and performance are better, and all customers love it because of these options.

The main benefit is that it is better in performance, provides security with App Protect and WAF and DDoS, and delivers high performance and high stability. However, there is still a major limitation in GUI capability to manage and observe. That is one of the major limitations.

NGINX Ingress Controller is doing better than the community edition for sure and works well when replacing Ingress Controller for OpenShift router. It is doing fine, but it is easy for the developer to develop and not easy for the other teams to work with. It is not something designed for a network security team anyway, so they cannot apply App Protect and other items. It is just for the developer. The drawback is that it is not targeting or is not easy for other non-developers to work with.

The capability to manage and observe should be better for NGINX Ingress Controller. We should not rely on Prometheus and Grafana so much. The management is still in Kubernetes Master, but there is a better way for managing it.

I have been using NGINX Ingress Controller for one year and a half. Coming from a background in network security and information security, it was not easy to recognize the deep involvement without having extensive reading about it.

NGINX Ingress Controller is working fine with both NGINX community edition and NGINX Plus. We cannot see a difference when using NGINX Plus instead of community edition in SSL/TLS terminations. The stability in SSL for NGINX Ingress Controller Plus, which is the commercial one, is better than the open source. However, I do not have comparison data with other vendors as I have never seen a comparison between NGINX Ingress Controller and other Ingress Controllers in SSL/TLS.

NGINX Ingress Controller is perfect for scaling. NGINX is really awesome in scaling.

I have had one or two cases open with them. They are fast in response, but they are at an average level. The F5 team, which is the BIG-IP team, is faster in response and resolving issues.

NGINX Ingress Controller as a reverse proxy itself, which I have already tested as a software as a standalone server and not just as an Ingress Controller, is perfect. As an Ingress Controller, it is doing fine. NGINX Ingress Controller must perform reverse proxy functions, path-based routing or host-based routing, and target which container to route traffic. It is deep technical work, but it is doing fine overall.

Configuration is simple to start. To get deeper, I need to be a developer.

Prometheus and Grafana are definitely necessary. The metrics I find really important is latency and request latency. That is one of the major metrics we love.

I have configured a new use case once in my life when something required it to work. I did not test it again after that, just once in my life.

Deployment works at small, medium, and large scales. I am working with different deployments.

For the sales and pre-sales, I simplify the message as much as possible. The message for NGINX Ingress Controller is always complicated when delivered, and it requires simplification.

I would rate this product 9 out of 10.

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.

The overall time and manual work have been reduced since we started using NGINX Ingress Controller. Earlier we used some other routing tools, but NGINX fits quite well in our Kubernetes cluster setup, making it easy to deploy and get running. NGINX Ingress Controller has helped my team reduce workload, particularly in the time saved.

The best part of NGINX Ingress Controller is how it works, particularly the annotation feature, which allows us to specify all our details through annotations, making it quite easy to integrate with our system.

The rewrite path is one of the annotations provided by NGINX Ingress Controller, which lets us route requests to a different path based on specified weights. For example, we can send 50% of the requests to one endpoint and 50% to another.

The annotation part of NGINX Ingress Controller is good, but it can be tedious when there are many features to specify in the annotation section, which sometimes gets messy and could be improved. However, there is a new project called Gateway APIs that has solved that problem.

The annotation part itself could be improved, as overall it was good but sometimes having everything in the annotation section can be a bit cumbersome.

Overall NGINX Ingress Controller is a good tool to use, but the main drawback is the annotation part, as managing many paths and features can get quite tedious and complicated.

I have been using NGINX Ingress Controller for more than three years now across my different projects.

NGINX Ingress Controller is stable in my experience.

The scalability of NGINX Ingress Controller is overall good for our needs.

The customer support for NGINX Ingress Controller is good. I would rate the customer support for NGINX Ingress Controller around a 7 or 8.

We were earlier using HAProxy to route requests, but we found it quite confusing and complicated, which is why we switched to NGINX Ingress Controller.

The main advantage of NGINX Ingress Controller is the deployment and ease of use. The way we deploy NGINX Ingress Controller is quite easy, as we just need the Helm install command or we can directly apply the YAMLs, which makes it unique.

We have seen a return on investment from using NGINX Ingress Controller, specifically in needing fewer people.

The pricing for NGINX Ingress Controller is overall acceptable, and I would not say it is great. The setup cost was also acceptable, and the licensing was straightforward.

Before choosing NGINX Ingress Controller, we evaluated options such as F5 and HAProxy, but we eventually started with NGINX.

NGINX Ingress Controller's governance and security features of AI capabilities are good, with all the basic guardrails available.

The accuracy and reliability of NGINX Ingress Controller's AI capabilities are not 100%. Sometimes it hallucinates and requires more prompting to get what I want exactly, but overall it is a good feature that still needs improvements.

NGINX Ingress Controller is a good tool to use. If you have a Kubernetes cluster, then it is easy to deploy and use, though you might face issues with the annotation part. I would give this review a rating of 9.