Moving To NGINX From Apache


I’ve been a longtime user of the Apache webserver. I think I first installed and configured a 1.x release somewhere in the late 90s, which is longer ago than I often realise.

The last time I looked at NGINX as an alternative to Apache was, similarly, quite a while ago. At the time, the feature parity wasn’t sufficient for it to replace what I needed my Apache install to do, which was a combination of outbound webserving and reverse-proxying of internal services.

A lot has changed. NGINX is now absolutely a viable alternative to Apache for basically everything I thought I needed Apache for.

It’s also just… easier.

The configuration syntax makes more sense to me. Name-based virtual servers just work. SSL setup is easy. I didn’t have to muck about to get reverse proxying working. Putting specific bits of configuration in a certain context (global HTTP server, virtual server, URI location) seems much more intuitive. The documentation is largely clear and to the point, and it’s easy enough to find what I need to look up.

To be fair, a lot of this was made easier because I was coming from Apache and already knew how a lot of this should work, even if I didn’t necessarily know what the syntax I needed was. It was just a matter of quickly Googling Apache to NGINX migration guides scattered around the place, and checking of some documentation.

Why Move?

Apache is pretty heavy. My main corporate site is hosted on a small virtual server to keep costs down, but the same VM also hosts a bunch of other services, like email. The VM only has 1GB of RAM, which should be a lot, but these days it unfortunately isn’t. Apache hogging a bunch of memory to serve up some pretty lightweight pages didn’t really make sense, but I hadn’t bothered to change because a) it worked, and b) why fix what isn’t broken?, and c) laziness.

Alas, the rise in spam meant spamassassin was chewing up a lot of memory learning new tokens (a topic for another day) and running out of RAM, or MySQL would run out and die when something got a bit too popular. It wasn’t worth building a multi-VM scale-out solution, because that would be massive overkill (which means I totally should do it as an exercise one of these days) but I don’t like operational headaches.

Recently I spoke to NGINX Head of Products, Owen Garrett about the open source NGINX webserver/proxy/cache/load-balancer, and the commercial offering NGINX Plus. Did you know there’s a commercial version? There is, and it’s about a lot more than just webserving. Oh, and the CEO, Gus Robertson, is a fellow Aussie.

So NGINX was top of mind, and I figured I may as well give it a go.

Easy Move

Installation is easy, because NGINX is part of Ubuntu, so just:

apt-get install nginx

Basic configuration was straightforward: add a site in /etc/nginx/sites-available, port the Apache configuration across, link to /etc/nginx/sites-enabled and then reload the server config. Here’s a decent place to start with how to port your config. It’s quite easy, really.

You can check syntax first, just like with Apache:

nginx -t
service nginx reload

I already had SSL keys organised (check out LetsEncrypt if you need some) so the main change was to concatenate existing server certificates and the CA chain certificate, because NGINX wants them to be in the one file (unlike Apache’s SSLCertificateChainFile syntax). More info on configuring SSL is here.

Setting up a reverse proxy is easy with the proxy_pass setup:

        location / {
                proxy_pass_header Server;

The servername and port are changed for this example, but that’s honestly all there is to it. I only need the proxy_pass_header Server; part because the application server this is in front of happens to need the requested hostname because reasons.

WordPress With FastCGI

This blog runs WordPress, and moving that to NGINX meant adding something to process the PHP, much like adding libapache_mod_php5 to Apache.

Again, this is easy:

apt-get install php5-fpm

And then configure your NGINX server to call php5-fpm as described in this article on the NGINX site. There are security implications for how you allow code to be executed on your webserver, which isn’t specifically related to NGINX, but basically don’t allow files that can be uploaded to the site to be executed as code.


For tips on the basics of migrating a config, check out this guide over at DigitalOcean. Also take a look at the Beginner’s Guide in the open-source documentation

The basics in the NGINX Admin Guide are easy to read as well, and you can refer to the detailed command references where you want to.

The basics of configuring NGINX for SSL is here.


  • There’s a difference between root and alias, which is important.
  • If you want to debug how your location matching is working, put your error logging at level notice, and enable rewrite logging, e.g.:
    rewrite_log on;
    error_log /var/log/nginx/mysite.errors.log notice;
  • debug level output is very verbose.
  • Move stuff you use in multiple places into a separate file and use include <commonfile>; so you don’t have to write the same thing over and over.


Bookmark the permalink.

Comments are closed.