Although NGINX conf 2015 took place back in September, not a day passes without someone asking me to summarize highlights from the event, future NGINX plans, what’s coming up, and related information requests, so I prepared this blog as an update on “what’s up with NGINX”.

But first, I would like to once again thank the NGINX team for organizing a fantastic (sold out) event at a a very cool venue: Fort Mason, San Francisco. With over 600 registrations the annual event was completely sold out!

Many worthwhile use cases were presented by different international speakers, and I’m really proud to say that I was one of them. Here is a link to my talk about Correlating Metrics Across the Continuous Delivery Pipeline:

The NGINX staff presented details about their product, new features, and an overview of their product roadmap.

Here are some highlights:

Igor Sysoef (@isysoev) talking about nginScript

I really like Igor’s presentations. He’s a very low-key presenter, but what he says is substantial, and when he speaks people listen. nginScript is a JavaScript engine integrated in NGINX, which allows the use of use JS in the configuration files. Igor: “I have tested a couple of existing JS engines, they are good, but have been written for browser environments. So I created my own!” Well, that’s Igor. Just like he created his own webserver a couple of years back, which turned out to be a very successful project. The first preview of the new functionality was announced at nginx.conf.

NginScript allows JavaScript code to be added into NGINX configuration files, which can either set NGINX variables for further use or execute entire code blocks and set content such as request or response structures. The current range of functionality is limited but we can expect ongoing enhancements.

For example, there is no garbage collection in the current version.  Instead, a separate VM is started for each request, and later killed, which makes a garbage collector unnecessary.

Rick Nelson talking about dynamically scaling of NGINX in a container environment

Rick generally does not talk too much theory and instead uses demos in his presentations, making them very practice-oriented. And this demo was really cool. His showcase was built of a couple of Docker containers for different purposes: one instance of NGINX Plus used as loadbalancer, two instances of backend nodes: one NGINX as webserver and one instances of Elasticsearch. A script was used to create load against the loadbalancer, while another script worked as an autoscaler: using the NGINX Plus status API and the dynamic configuration API to scale up and down the environment based on the incoming load.

Ruslan Ermilov talking about Dynamic Modules

Well, this is really gonna be awesome! Currently it’s possible to create your own modules for NGINX, but they need to be compiled into the core. Modules that can be loaded dynamically per configuration are currently not possible. On the one hand that makes sense, because NGINX is designed to be a lightweight HTTP server, reverse proxy, load balancer, and more, and adding too many, possibly poorly designed, modules, could negatively impact performance. On the other hand, NGINX is widely used in the internet, and there are more and more requirements for additional functionality. While a module can easily be created and loaded into NGINX open source, NGINX Plus will only accept modules that have been certified by NGINX, Inc. so the user can be sure that the module does not burden the base functionality of NGINX Plus.

Overview of Andrew Alexeev NGINX Amplify presentation

While the extended status API is only available for NGINX Plus, Amplify will also be available for the open source version. Amplify, which runs as a daemon process on the host, is a monitoring tool for NGINX webservers. It collects information provided by the open source status API and combines it with host and process metrics like CPU, memory, Network I/O, and Disk I/O. These data are sent to an Amplify server and made available for the user in a web UI. Charts can easily be arranged and used for correlating data.


Another very cool feature of Amplify is that it automatically detects the running binary and checks whether it’s a well-known version from a distribution environment or a custom build. It also shows a list of modules that have been compiled into the binary. And, even better, it also checks the used configuration files and provides hints and warning if there are configuration options that might encounter undesired situations. This information is created with feedback from the NGINX support team and reflects issues that were reported by customers.

I’ve been using NGINX for quite a while. In the beginning I started to test it because of its high performance, and this is still the case. But now there are more reasons for using it, particularly the ease of configuration. I am very impressed with the location blocks concept, and the fact that NGINX processes event-based web requests, and does not fork new processes or threads, makes it very lightweight.

Just before the conference, NGINX became the number one webserver among the top 100,000 websites (relegating Apache to second ). In the top 1,000 and 10,000 categories this had already been the case for some time. In total there are more than 140 Million websites using NGINX.

That’s it for now, but stay tuned for more NGINX developments! I’m confident there will be more!