The original API performed a synchronous Nginx reload after provisioning a zone, which often took up to 30 seconds or longer. While important, this step shouldn’t block the response to the user (or API) that a new zone has been created, or block subsequent requests to adjust the zone. With the new API, an independent worker reloads Nginx configurations based on zone modifications.It’s like ordering a product online: don’t pause the purchase process until the product’s been shipped. Say the order has been created, and you can still cancel or modify shipping information. Meanwhile, the remaining steps are being handled behind the scenes. In our case, the zone provision happens instantly, and you can see the result in your control panel or API. Behind the scenes, the zone will be serving traffic within a minute.

Nginx serves as the loadbalancer, router and SSL terminator of cloudcraft.co. As one of our app server nodes is spun up, an Ansible orchestration script adds the new node dynamically to the nginx loadbalancer config which is then reloaded for a zero downtime seamless rolling deployment. By putting nginx in front or whatever web and API servers you might have, you gain a ton of flexibility. While previously I've cobbled together HAProxy and Stun as a poor man's loadbalancer, nginx just does a much better job and is far simpler in the long run.

Used nginx as exactly what it is great for: serving static content in a cache-friendly, load balanced manner.

It is exclusively for production web page hosting, we don't use nginx internally, only on the public-facing versions of static sites / Angular & Backbone/Marionette applications.

We use NGINX both as reverse HTTP proxy and also as a SMTP proxy, to handle incoming email.

We previously handled incoming email with Mandrill, and then later with AWS SES. Handling incoming email yourself is not that much more difficult and saves quite a bit on operational costs.

NGINX sits in front of all of our web servers. It is fantastic at load balancing traffic as well as serving as a cache at times when under massive load. It's a robust tool that we're happy to have at the front lines of all Wirkn web apps.

We use httpd in front of our Tomcat web server. Apache terminates the TLS connections and forwards to the embedded Tomcat server(s) for request processing. We also use it as load balancer for multi-server deployments.

Most known webserver. We are using Apache due to his htaccess feature but its just a backedn to proccess PHP. In font of Apache we are using NGINX to server static files

Apache splits static traffic from application traffic, as well as providing a selection of tools to assist in running of the site (rewrites, logging etc).

Primary web server, delivers PHP-rendered pages as well as static HTML content. Ruby CGIs deliver objects to browser-side code using REST/JSON

modproxybalancer provides highly concurrent end-user browser connections, and manages session routing to the application cluster

Application/http-server for everything except static data.