NGINX

We use the NGINX forward proxy manager to manage a few sites coming into the network. all websites with different domains.

I use NGINX when building POC labs in Azure and AWS to demonstrate IaaS solutions. Both as a simple test web server or as a reverse proxy, depending on the specifics in the POC.

NGINX is a gate to our application; it is a great open-source product, one of the best out there.

We use NGINX as our web-facing server, behind which we have a collection of services serving various parts of our application. NGINX helps us map a single API over a variety of services, and make our API endpoints consistent across the various services. Nginx also helps with uptime, by helping us switch between various instances of the services in near real-time.

We have used NGINX in several different ways. We've used it as a load balancer, a proxy server, and a web server. Its ability to do one or all three of these jobs is what makes it so useful.

We use Nginx as a load balancer and as a reverse proxy for all of our web services. We use it to serve NodeJs applications, REST APIs and Angular front.

Ever since discovering Nginx as an alternative to Apache, it has been my web server of choice for a variety of purposes, whether it be creating a versatile development server accommodating a variety of platforms across many different sites, or setting up a high-speed scalable server with integration with a popular content management system for a client. The powerful yet flexible configuration options of Nginx makes it straightforward to configure a server for a multitude of different tasks, and a clear choice for almost any situation.

We use Nginx to serve static content for a few of our applications. Nginx is very effective for us because it's free, scales very well, and can handle millions of requests a second. It has made several of our websites noticeably faster. In addition, its ability to act as a Proxy/Reverse Proxy has been instrumental in fulfilling our specific web hosting needs.

We use Nginx as the primary reverse proxy for all of our web services. We manage several dozen web applications, for many different clients, and Nginx allows us to quickly route requests to the correct service. Since we use Kubernetes to manage services, it is fast and simple for us to add new routes to our Nginx service. Nginx also manages our SSL, allowing us to deliver content securely.

We used it to deploy web applications built using popular JavaScript frameworks such as Angular and React.

Nginx is powering the serving of web content across our entire organization. We used to host over a hundred web servers with Rackspace Cloud all with nginx sitting in front of backend server processes. Now, we host the majority of our sites on Pantheon, who also utilize nginx in their app server layer. We also host a number of custom servers on AWS EC2 which serve web content over nginx. It allows us to squeeze more performance from our web servers much more easily than using Apache.

I have used Nginx for years to serve Ruby on Rails applications for a number of clients and with various integrations including Passenger and, more recently, Unicorn. I have found Nginx to be a wonderful choice for both standalone server and layer in front of Unicorn. Nginx excels at serving static files, load-balancing, security (preventing certain exploit attempts) and simply acting as a front end for full-featured application server back-ends.

Nginx is used as the main web server and load balancer in front of our Rails apps. We use Nginx + Passenger together as part of our stack for production deployments of our Rails apps.

We currently have 5 different deployments of Nginx, and everyone in the company that deploys production apps uses them.

The main business problem addressed by Nginx was definitely speed and load balancing. Before using Nginx + Passenger, we had Apache servers in front of Mongrel for our rails apps, and they not only were slow and memory intensive, the only load balancing strategy available with that setup was round-robin allocation of incoming web requests to different app servers. With Nginx, it acts as a load balancing proxy as well and keeps track of which app servers are free to receive new requests. This resolves bottlenecks in our server's performance.

Nginx is my default go-to web server for all Linux web servers (LEMP Stacks) that I currently deploy. I use NginX primarily as one of several pieces of a custom-designed web-server stack in conjunction with Ubuntu or CentOS, Percona XtraDB, and HHVM with PHP7-FPM failover, which is used to power PHP based websites (such as WordPress) which I deploy on entry-level compute packages provided by industry standard cloud services (AWS, Google, BlueMix, Digital Ocean) for our web-design clients. My primary goal with these servers is to provide our clients with their own managed, in-house hosting solution with more power than a standard hosting company can provide, but at a similar recurring cost bracket. Nginx was my choice, as it was designed specifically to win the C10k challenge, which was a challenge to create a web server capable of handling 10,000 simultaneous connections on a single server (which was successful). The biggest challenge I face is designing a stack that can handle a potentially heavy connection load while deployed on low-spec, shared-resource, sub-$20 virtual servers, while avoiding the expensive, constant need for computing resource increases. These challenges require a web server than can handle 1 or 1,000 connections on the initial specs, without an increase in resources, which Nginx was able to accomplish beyond my expectations, allowing me to provide similar and sometimes equal performance on virtual servers as that of higher-cost, WordPress specific hosts, such as WP Engine.

Nginx is a http server software used to serve up websites across the web, similar to Apache httpd. The main difference being that Nginx offers multi-threaded support to serve up websites faster and more efficiently. I implement and use it as often as possible for my websites I build in order to provide the speed and efficiency that is required. It is easy to use one config file to serve up both the http and https versions of the site.