NGINX Plus Reviews

Proxy and load balance are the reasons why I use NGINX Plus. I use NGINX Plus to help me with a delivery app on the cloud for one of my company's customers.

The most valuable feature of the solution is that it is simple to configure.

The solution's GUI is an area with certain shortcomings that need improvement. The price of the solution is also an area that needs improvement.

In the future, I would like to see the solution to have better capabilities in terms of basic checks and reporting.

I have been using NGINX Plus for two years. I don't remember the version of the solution.

Stability-wise, I rate the solution an eight out of ten.

Scalability-wise, I rate the solution a seven to eight out of ten.

I rate the technical support a nine out of ten.

Positive

The initial setup of NGINX Plus is very simple to deploy since it is done on a cloud.

The solution is deployed on the cloud.

The cost of NGINX Plus is high. NGINX Plus is an open-source solution with limited additional features. When you try to get additional features in the solution, then you need to pay an extra amount to NGINX Plus.

NGINX Plus offers limited functionalities when it comes to load balancing.

I rate the overall solution a six out of ten.

I use NGINX for load balancing, and I use the solution's Reverse Proxy to get different domains and certificates into our server.

I need to highlight that the number one thing about NGINX is that it is free. Aside from that, for big companies who want a lot of traffic and a big work block, we can build the solution for them.

NGINX needs to improve its factory hardware. Some start-ups keep changing their technology over time to improve control over traffic and function. NGINX needs to improve its performance.

It would be good if NGINX provided a graphical user interface. We currently need to work on configuration files. It is difficult for fresher engineers to work on the solution.

I used NGINX for one project, so I used it for about one or two weeks. I might use the solution again one or two weeks later, but I don't work with it continuously.

The solution is very stable. Any problems will be because of the engineer working on the solution and the product itself.

The initial setup is not simple. We have three people working on the solution.

I have compared NGINX with HAProxy because both of them are open-source software. NGINX is faster than HAProxy.

We used the solution on-prem, but if the customer demands it, we can deploy the solution on the cloud. NGINX is suitable for small, medium, and large enterprises.

We have faced problems on NGINX that we could not figure out using the documentation, so we asked the online community for solutions.

I rate NGINX a nine out of ten.

So it's primarily for testing purposes.

With NGINX, I appreciate its ability to route traffic geographically. It acts as a proxy in the middle, which helps us manage traffic flow in complex networks. 

It takes the load off the actual mission-critical applications and transfers the traffic to the main applications with less burden. It's a very useful tool to have in your profile.

One thing I would love to see is a feature similar to what Elastic offers. When Elastic receives data from any server endpoint, it allows you to either save it into an index or print it on the terminal. While debugging and testing the load balancer, it would be helpful to have the option to print data on the screen. This way, we can verify that the load balancer is receiving the correct data and displaying it on the screen. 

If this feature exists in NGINX, it would be great to have a flag or switch that enables displaying data on the terminal for verification of network traffic.

NGINX is a very lightweight tool. We deployed NGINX on a simple, minimal specification machine. We used the configuration provided by Wazuh on its documentation website. The only thing we had to do was provide the IPs of our own machines. Everything else remained the same. After that, we were able to load balance the traffic from all the endpoints.

This was our first experience with NGINX as a team. We used it specifically for load balancing across all those endpoints. Apart from that, we don't work with NGINX.

We have been validating Wazuh for one year, and we have been using NGINX for almost two months. During the testing phase, we had to ensure that NGINX met all the requirements for building a redundant custom solution, including multiple nodes and a load balancer. However, during testing, we didn't require any additional load balancing or extra functionalities.

It is stable. We have faced connectivity issues only once or twice. Otherwise, it has been working fine.

We haven't encountered a use case that required us to scale NGINX. We have two NGINX instances in Wazuh cluster, which helps distribute the load across different servers. So, as of now, no scaling requirement for NGINX.

Currently, I am the only person working with NGINX.

We inquired about the procedure for official support from Wazyh itself. They provided us with a price quote based on the number of endpoints we would be covering. However, we haven't purchased that. We are currently using the open community and Slack for support.

The initial setup was not complex. It was easy. It took us one or two days to set it up.

The deployment was simple. We used the Linux installation command, and then we followed the configurations provided by Wazuh. We copied and pasted the configurations into the specified directories. We replaced the tags with our own IPs, and we were good to go and start using NGINX.

Currently, only one engineer, which is me, has been managing Wazuh for the past year. NGINX does require maintenance. Maintenance is usually not required unless there are rare cases of design changes or version upgrades. We rarely need to schedule a maintenance window for Wazuh, maybe once or twice every six to four months.

We are currently using the free version of NGINX. No costs have been incurred yet.

We had other solutions like BIG-IP.

I would recommend watching videos, YouTube tutorials, and concise documentation related to the specific use case. For example, in our case, we focused on load balancing, so we referred to the version documentation on how to configure NGINX as a load balancer. Also, make use of the official NGINX documentation.

I would rate it around nine out of ten. It hasn't disappointed us, and for our use case of load balancing, it performs exceptionally well. So, a solid nine every time.

The load balancer which is based on NGINX is used to protect our servers. The product works as a reverse proxy and we use some modes and smart security modules of NGINX for securing the web application as a web module.

The solution has provided us with a resilient IT infrastructure and it can also provide the reverse proxy features for securing the web application and netting a particular client's IP. NGINX has created a resilient infrastructure for us which has reduced our downtimes. 

A valuable feature is the very high-performance load balancers on HTTP and it's also great that the product supports IMAP, POP and SMTP protocols for the reverse proxy.

The KPI on NGINX Plus should be more focused on load balancing and the latency in application calling from the end system. That is something currently lacking in the solution. I would also like to see a very interactive dashboard with all the KPI metrics that would help with application level troubleshooting. Finally, most people implementing this solution do not include a security model and it would be great if they could include that in the product. 

I've been using this solution for three years. 

The solution is stable. 

The solution is scalable, we can host many websites. We have around 1000 users.

We haven't contacted the support. I've read the documentation and it's quite good and sufficient for our needs.

NGINX is a little complex to implement and requires a certain level of knowledge including at the application level when different websites need to be redirected.  Using the redirection requires some knowledge about the application aspect and that's somewhat complicated. Deployment was carried out in-house. We're currently using 10 nodes and we won't be expanding in the near future. 

We are using the open source version of the solution. 

We also evaluated Apache but NGINX had more suitable features. 

I rate this solution nine out of 10. 

We primarily use the solution as a proxy in communities. We’ve got some latencies in the database connection and some connection drops, so we use the proxy to make the database relevant. We use it for all the websites, the APIs, et cetera.

The web proxy and the database proxy are excellent.

It offers a lot of very helpful, useful features that I really like. There are too many to name.

I can’t speak to where the solution needs improvement. I’m just a user and I haven’t really gone in-depth in terms of looking for where the solution might have weak points.

It would be great if there was even more automation to make it even easier to maintain.

We’ve been using the solution for twenty years at this point.

The stability has been very good. It’s reliable and easy to deal with. There are no bugs or glitches. We haven’t had any issues with crashing or freezing.

In terms of scalability, everything it has is good for us. We have everything redundant. We use HP Proxy 2 to make it load balancing. We haven’t had any issues with scaling.

We do not plan to increase usage at this time. We’re pretty small. We don’t have to operate a lot.

We did previously use a different solution for two or three years. We needed to have some security features, which made us move to NGINX.

I don’t have any insights as far as the setup goes. I came to the company after it was deployed.

However, my understanding is that it wouldn’t be complicated as everything is automated.

For maintenance, we have two people managing the solution.

We handled the initial setup on our own, without any outside assistance.

For us, the solution is pretty affordable. We don’t use it too much. It’s inexpensive for our setup. That said, I can’t speak about the exact cost.

I’m just an end-user.

I’d rate the solution a ten out of ten. I’ve been very pleased with its overall capabilities.

We are just copying some of what is on the F5 to the NGINX and seeing how it behaves. We will start with the streaming servers.

The load balancing module, which is equivalent to LTM, is the focus of the PSE. So far, the features of both are identical. I believe NGINX has more features for securing these services, but in terms of load balancing, both are massive solutions.

We are still learning. I can't tell you.

It is still in the POC phase. It is not yet live. Running it as a proof of concept is never the same as having it in production.

It's currently a POC, and things are going well so far. We haven't gotten too far into advanced topics. We are still in the early stages of setting up VMs, routing, and more but things are going well so far.

Because we are in the POC, I would need more time to comment on stability. We haven't even finished or published the proof of concept. We are still in the preliminary stages.

In terms of scalability, we have not yet scaled up. We have a basic setup where we have a VM that acts as a load balancer, and the controller. 

Scaling up means adding more VMs to the cluster; it's as simple as that, but it's a feature that F5 lacks.

We have not yet contacted technical support.

We are still using F5.

The architecture is slightly different from F5 because it is based on VMs. F5 has an appliance, but it's a legacy style, whereas NGINX has both the VM and the appliance. The controller, which controls and pushes configuration, and the orchestrator are both parts of the VM. It is not difficult; it is simply different.

It took me about two or two and a half months to install this solution while I was experimenting with it, but that doesn't mean it's difficult or difficult to accomplish. It's new to me, and I'm following the instructions to get started with the solution.

It only took a few hours for the third party to implement everything from A to Z.

The POC is handled by a third party because we would need the license as well as the VMs or images. This must be supplied by a third party.

This would follow the technical evaluation. After that, we'll meet with the commercial team to go over these details. But, as of now, I have no idea how much that product or solution costs.

Because the solution is modular, it is not like F5, where you pay for the box, then licenses, and that's it. You pay for each feature that you want. It has both benefits and drawbacks. The benefits, in my opinion, are that you can pay for whatever you want. The drawback is that you must obtain a license for everything.

It is difficult to offer advice. I want to be completely objective about both products.

I would require more time. I haven't even discovered 20% of the features. NGINX Plus is more than just the load balancing module. It has a number of other modules and features.

I would rate NGINX Plus a seven out of ten.

We use this solution for caching. We are customers of NGINX.

This is a great product, it has everything. 

The center management system was not very good, maybe their new NGINX manager product is better. I'd like to see a good web management interface in the next release. 

I've been using this solution for three years. 

The solution is stable. 

The solution is scalable, we have around 1,000 users. 

The technical support is very good. 

The initial setup is straightforward.

They offer a free product, but there's a license for the more advanced features like API gateway. It's a mid-range cost. 

It's worth learning Kubernetes because NGINX is generally deployed in the Kubernetes environment like ingress controller. 

I rate this solution eight out of 10. 

We build all our websites (of which we have multiple, from production sites to development environments), through webpack, so we use NGINX to quickly host them, while easily binding to the relevant (sub)domains. Our entire service stack runs on Linux. Our most challenging part was to run an older PHP website reverse-proxied through NGINX. That was not fun.

NGINX isn’t itself a productivity tool, but rather a cog in the engine of a solid service stack. In a way, it's the same as adding RAM to a PC. While you don’t necessarily feel the new improvement, you’ll definitely know when it’s gone.

Our primary use for NGINX is as a Web server, so that’s where we derive the most value. Recently, we’ve needed to deploy sites over a number of servers to balance the load, which was not only painless but also super valuable.

We used the standard tried-and-tested features of NGINX. Everything is done through the CLI over a secure connection and there have not been any issues or additions to our wish list.

NGINX has an amazing developer base which ensures amazing stability.

We’re only just getting into the scalability side of things, so no issues yet.

Never needed technical support (which speaks for itself).

We tried to use some "golden bullet" solutions but we never needed most of their features (like a built-in database environment). NGINX is a direct way to satisfy a specific need.

This was installed on an Ubuntu system. The setup and deployment is well documented which lead to creating an easy hosting environment.

The idea of using other lightweight solutions, or a native Ubuntu Web server, was completely overshadowed by NGINX.

Support the developers and the product, they’ve worked really hard to give you something you’ll always be satisfied with. First, set up a free environment and see your limitations, and then pay for what you need.

Always do a setup and test on a small (possibly in-house) server. Work out all your kinks and processes, then deploy it to a production environment. Having something like docker helps immensely.

I rate NGINX a 10 out of 10. Really, the only other options are native solutions that are either super convoluted or don’t have the needed features.