NGINX Plus Reviews

I primarily use NGINX Plus as a reverse proxy, and it does an excellent job. 

NGINX Plus is a crucial tool that helps me tackle various problems and challenges. Its versatility and capabilities make it invaluable for implementing patches and fixes when necessary.

NGINX Plus is incredibly valuable to me because it excels at being a reverse proxy, offering seamless failover, and it works perfectly for my needs.

Improvement needed in NGINX Plus could focus on optimizing memory usage for users.

I have been using NGINX Plus for two years.

I would rate the stability a seven out of ten.

The product is very scalable. I would give it a ten out of ten for scalability.

Technical support is very good. I have used it only once and it is great. I would rate it a ten out of ten.

Positive

The initial setup is very easy. 

I have definitely seen ROI with NGINX Plus.

I believe NGINX Plus offers very reasonable pricing for companies. Although I didn't buy it myself, companies that did found it to be affordable, especially with free versions available for specific needs.

I would recommend NGINX Plus to others. It is a good product and it is very user-friendly. Overall, I would rate it a ten 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.

We have two to three use cases for the solution. The first use case is for our organization’s Base Server that is hosting the applications. The second is the load balancing and reverse proxy. The third use case is NGINX App Protect which we are using right now.

I find the solution’s community support and documentation most valuable. Compared to HAProxy, have found a lot of documentation and community support on Quora. If you would be asking me as a developer whether to choose this product, I would recommend this since it has good community support, documentation, and signature updates. The configuration of HAProxy is also very tedious. However, NGINX’s configuration is very simple.

I would like to see the Grafana integration in NGINX which is already present in HAProxy. Grafana integration will help the solution visualize all the data analytics on the dashboard which is currently not present.

.I have been using the solution for more than one and a half years. I use the solution’s latest version.

The product is stable.

The solution is scalable.

I used HAProxy before NGINX and I switched to the latter because of the documentation.

The solution’s implementation is very straightforward. The deployment takes around two to three days to complete. However, the solution’s implementation will depend from organization to organization. Some of the packages can be blocked by their BLP. If a company has full internet access, one to two days would be enough to do the POC. In fact, one hour would be enough if the company has full internet access.

We use CLI-based installation process in docker. If you use docker filing for the solution, then the installation is too easy. You can build a server within two to three minutes if you have the image of the application.

HAProxy is cheaper than NGINX.

I would rate the solution a seven-point five out of ten. I would recommend the solution because of its community support.

NGINX can be used for publishing services or as a replacement solution for web services, like Apache, and it can get updates from servers.

We had a lot of attacks in the network, and most of them were based on Apache. About three years ago, we decided to go for a new solution.

There are about 2,500 users in my company. Our company is an international company, and we're growing. We're going to hire 500 people in the next six months.

It can be deployed on a private or public cloud.

The most valuable features are the gateway and the ability to publish to sites.

The scalability could be improved.

I have used this solution for two years.

It's a stable solution. It's good for load balancing and clustering.

We haven't used technical support. It's an open source solution, so we search the internet if we have any issues. We also do tests before implementing on a real server.

We previously used Apache. We switched for security reasons and because Apache couldn't be upgraded. It had a lot of security vulnerabilities.

Setup is very easy. It's easier to set up than Apache. There's a lot of documentation on the internet.

If someone is knowledgeable, they can implement the solution in 30 minutes. It depends on the infrastructure and the services in the company.

It's not a complicated solution. One or two people can implement it.

It's an open source solution, so it's free.

I would rate NGINX as ten out of ten.

I would recommend this solution to those who want to start using it because it's a good solution and it's free.

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.

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.