The Next-Generation PHP Server Stack For 2015

Want to help support this blog? Try out Oh Dear, the best all-in-one monitoring tool for your entire website, co-founded by me (the guy that wrote this blogpost). Start with a 10-day trial, no strings attached.

We offer uptime monitoring, SSL checks, broken links checking, performance & cronjob monitoring, branded status pages & so much more. Try us out today!

Profile image of Mattias Geniar

Mattias Geniar, November 30, 2014

Follow me on Twitter as @mattiasgeniar

The server stack surrounding PHP hasn’t change much in the last few years. It’s still roughly the same as every year, give or take a few minor tweaks here and there. But 2015 may be the year where some of these services get swapped out for new, improved, ones. Only time will tell of course, but here’s my take on the PHP server stack for 2015 (and hopefully, later).


For just about every project (obviously not limited to PHP), Varnish is a standard part in the setup. In 2015, Varnish 4.0 will be the new standard, where it’s currently mostly Varnish 3.x.

Varnish will continue to serve its purpose running on port :80 of your server, ready to handle the bulk of the load. If you can avoid hitting PHP and the database, you should – no matter how fast PHP parsing is about to become.

Apache or Nginx

The webserver will still be either Nginx or Apache, depending on the experience of the sysadmin with either of the webservers, or the requirements for the project. The webserver itself will be configured to be as “dumb” as possible: serve static files, perform compression and send the request to the PHP service for further processing.

The days of mod_php and slow FastCGI/CGI scripts are far gone.

SSL termination via proxies

In order to fully utilise the Varnish cache, all requests need to pass by it. But SSL requests are terminated on port :443, and Varnish is unable to perform SSL. Depending on the webserver of your choice, Apache or Nginx, it’ll be set up to act as a SSL proxy.

All requests that come in via HTTPs are passed via the proxy, that only does the SSL termination / encryption, and passes the request on to Varnish on port :80. Once in Varnish, it’ll either serve a page from cache or forward the request to the real virtual host running on another port.

The benefit of having the Varnish cache, together with SSL encryption for your project.


While Facebook’s HHVM is faster than PHP-FPM today, the new php-ng may be able to change that. The speed results of php-ng do vary, but it’s rumoured that at release, it should be at least as fast as HHVM. What’s now known as php-ng will most likely become PHP 7, and I’m hopeful to see it released in 2015.

Next up: code compatibility, as a next major version can perform backwards incompatible code breaks. Code written today will probably not work on PHP 7.

Right now, for raw performance it needs to be HHVM. But PHP-FPM has its merits as well, with flexible configs, multiple pools supported and decent performance in the 5.5 version and later. For most setups, PHP 5.5 or 5.6 running as PHP-FPM will be the default, and it will suffice. For those projects that need more performance, HHVM should be consider, until php-ng is released.

PHP-FPM or HHVM will run as Unix socket on the local box, or on a TCP/IP port when it’s run on a remote system, and will receive all requests from the webserver that it couldn’t handle.

MariaDB and MongoDB

Most have replaced their beloved MySQL with MariaDB for a few years now. In those years, MariaDB 5.5 was considered the standard, but 2015 will be the year where MariaDB 10.0 will see greater adoption. We’ll still see MySQL server as well, but it’s in the decline: MariaDB is taking over as default RDMS on most Unix distros since the Oracle license change to MySQL, and we should embrace the choice. MariaDB has replaced MySQL.

In the PHP community, MongoDB appears to clear winner in the key/value and document datastore. There’s plenty of (worthy) alternatives, but 2015 will still favor MongoDB over those others.

Memcached or Redis

For years, Memcached has been caching layer for many PHP developers. Its simple setup and usage make it very easy to implement and master. It’s simple protocol make it easy to debug.

The new kid on the block that made its appears a few years ago is Redis, which offers some additional benefits to Memcached (such as persistence to disk, transactions, clustering, > 1MB of data per object, …). Yet I’ve not seen Redis be used that often. And I’m doubtful as to whether 2015 will make a big change in that.

Memcached does the job perfectly: persistence is not needed in a caching layer (for 95% of all projects out there), clustering has historically always been handled either in the PHP code or in the PHP.INI configs (for instance, for the session handling in Memcached) and has proven its worth. Redis seems like it’s too complex for a simple task as acting as a caching layer.

However, if you’re going beyond just caching and are working on pub/sub messaging, need more availability from your cache or are looking for a queue’ing mechanisme, Redis can be used to replace the current Memcached. There’s probably little point in running both Memcached and Redis, so Redis would replace the Memcached service.


NodeJS isn’t PHP, obviously. But it’s used more and more as a supplement to PHP code. Need to run background jobs, process queue’s and more? Then the step from PHP to NodeJS isn’t that big. It’s JavaScript, on the server-side. And PHP developers know JavaScript.

The choice for MongoDB is also supported by the rising of NodeJS in the PHP community, as it’s most often used as the backend for NodeJS operations.

Deployment tools

There’s just too much choice out there. There isn’t a right tool, nor is there a perfect tool. They all perform their jobs, as long as you configure them properly.

For me, the clear winners remain Phing and Capistrano, where Phing could be considered the easiest to setup as it’s built on PHP, whereas Capistrano has additional Ruby + Gem requirements.

As long as your build-chain is automated and doesn’t rely on manual actions, you’re good to go – no matter what tool you’ve built this on.

DevOps Automation

For those PHP developers that manage their own servers, the configs will go into a Configuration Management System like Puppet, Chef, Ansible, SaltStack, … Whatever technology you’re most comfortable with, will be the winner.

It’s perfectly combined with Vagrant for local development that is an identical setup of your production setup. If you haven’t been using Config Management in 2014, be sure to put in on your todo-list for 2015. And if you’re just getting started, do not have a too complex of a server setup and want to get started quickly, consider Ansible.


PHP’s default shared-nothing architecture make it ideal to be placed in containers like Docker. In 2015, we’ll see more PHP projects be placed into Docker containers, but it’ll be the minority. Since Docker introduces additional complexity and management, it’ll only be considered by projects that have an actual problem to solve, where Docker can be the answer.

Eventually, Docker can supplement Vagrant for quicker development environments (instead of having Vagrant boot/manage VirtualBox VMs) and can replace the existing deployment tools for continuous integration.

Docker is on my 2015-todo-list, for a variety of reasons.


Since PHP has a long trackrecord already, it’s in a stable position. The current PHP 5.5 and 5.6 setups are built on years of experience, of learning from mistakes and making continuous improvements to the configs.

2015 will not be a dramatic change to this: HHVM or php-ng will make their grand appearance, but virtually all other parts of the stack remain as they are now. After all, why change a winning team?

As for the deployment or automation side, Docker can be a real game-changer, but so far hasn’t been adopted widely by the PHP community.

Want to subscribe to the cron.weekly newsletter?

I write a weekly-ish newsletter on Linux, open source & webdevelopment called cron.weekly.

It features the latest news, guides & tutorials and new open source projects. You can sign up via email below.

No spam. Just some good, practical Linux & open source content.