The primary use cases involve using NGINX for various features including WAF, API security, DDoS protection, and bot protection. Additionally, it facilitates network discovery and provides visibility into network activities, allowing us to uncover solutions and identify any areas we might have missed.

I utilize NGINX for its capability to provide visibility and discovery options. It helps discover and identify networks, which is crucial for ensuring application performance, managing latency, and checking server reachability. NGINX communicates with XE and uses Linux command terminology, thus providing visibility by interacting with the nearest POP.

The need for human involvement is high due to the complexity of NGINX's Linux-based terminology. More tactics and techniques can enhance its usability. Additionally, it is not a cost-effective solution for few applications.

We have been using this technology for the last five to ten years, so we are familiar with how it works.

I have not encountered any challenges with NGINX's stability, as it works effectively with Big IP, XC, and Palo Alto.

Support is available in the market with options like FYSE, which provides assistance during critical tasks.

We have experience using Palo Alto Networks, Sophos, SonicWall Firewalls, and other technologies.

NGINX is not cost-effective, especially for few applications, and is considered higher-priced.

Alternatives evaluated include Redway, cloud solutions, and services providing CDN options. Some gaps exist in NGINX not covering certain API options.

I would rate the solution an eight and a half out of ten. It's important to understand the requirements before recommending its implementation.

We use NGINX as a reverse proxy. For example, if you access www.google.com, NGINX accepts the external traffic and forwards it to the internal application servers.

NGINX can also be used for load balancing, which makes it better than Apache in a lot of cases. Additionally, it functions as both a reverse proxy and a web server, offering a lot of flexibility.

Moreover, it performs very well. That's one of the primary reasons we use NGINX.

I would like the configuration process to be more simplified. Both Apache and NGINX involve some complex configuration steps. Easier configuration and troubleshooting would make it a perfect ten for me.

I've used NGINX Plus for about one and a half years. However, I'm not actively configuring it right now since I'm working on microservices.

I've deployed NGINX Plus both within AWS EC2 instances and on our on-premises virtual machines.

I haven't experienced any major performance issues.

Around 100 people had access to it. In my previous team, around 10 to 14 engineers were actively using it for configuration and management.

It's quite scalable. We can host multiple frontend applications on it.

I used Apache. I configured Apache as a web server for a front-end web application deployment. I used it on a Linux virtual machine.

I actively used Apache for over a year. We configured applications for front-end hosting and used Apache as a web server to route traffic from the public to the virtual machine. It was listening on port 80 or 443 and forwarding traffic to the internal application.

I used it more than a year ago. Since then, I've primarily been using NGINX.

I've installed NGINX several times, and it was straightforward. It was not a tedious task, so the process was easy. 

NGINX's graphical user interface is fine. I've deployed frontend applications.   

There's an open-source version of NGINX that is free. There's also NGINX Plus, which is a paid version with additional features.

I would recommend it because it's a very versatile tool for load balancing and other scenarios. For example, you can use it to host front-end applications.

I would give NGINX an eight out of ten. It's great for load balancing, reverse proxying, and serving as a web server. Its versatility makes it superior to Apache in many ways. I haven't tried other similar tools, so that's why I wouldn't give it a perfect 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.

I use the solution as a reverse proxy. 

The product is lightweight and fast. 

The solution needs to be easier to setup and deploy. 

I have been using the product for two to three years. 

I would rate the product stability a ten out of ten.

I would rate the product scalability an eight out of ten. 

The tool helps us to improve our website speed. 

I use the solution's community edition which is free of cost. 

I would rate the solution a nine out of ten. You need to be careful with the product's configurations. It is easy to maintain.