Actually - before we dive in, thanks to Kevin Cupp from EllisLab who brought his ExpressionEngine and Varnish experience to the mix. And to Steve Rowling from Springworks, Andrew Armitage from Armitage Online, Peter Lewis and John Moylan for coming by and making it a good day.

What Does It Do?

Varnish acts as a HTTP server that sits between the user and your actual website. It's an intermediary server.

Once running, you would point your DNS to your new Varnish server - and that Varnish server points to your Apache (or similar - but I'll refer to Apache) server.

When a visitor requests a page on your site Varnish will check if it has a copy of that page. If it doesn't, it will grab it from Apache and then add it to it's cache before serving to the user. Typically that cache is stored on RAM, not disk.

Because it loads from RAM and has it's own lightweight HTTP server it's REALLY quick.

The Basic Setup

Kevin Cupp described the setup for Varnish on ExpressionEngine a little while ago on the EllisLab blogwhich covers the installation process but since that was published things have changed a bit. It's worth reading that up until he gets into VCL configurations and then come back here for up-to-date instructions.

During the Dev Day Kevin kindly came up with an updated VCL that works with Varnish 4 which I've added a few notes on this Github Gist.

Things That Tripped Us Up

When setting up Varnish on the dev day a few things tripped us up:-

  • I had Varnish set up for port 80 and MAMP had a few sites also on port 80. It didn't throw an error but wasn't loading via Varnish. Moving the sites to port 8080 fixed it.

  • When installed via Homebrew (as described in Kevin's original post), varnishd can be found in /usr/local/Cellar/varnish/4.0.0/sbin/ (although 4.0.0 will change depending on your version)

  • If running on a Mac you will have to run sudo chmod -R 777 /usr/local/var/varnish to get Varnish to load.

Once this is all running, just fire sudo ./varnishd -a -f /path/to/your/config/file.vcl -s malloc,200M and Varnish should start running.


Things get more tricky when we're dealing with dynamic content. Things like shopping carts, member bars, even dynamic breadcrumbs could be a problem if they're cached.

To solve this you can use Varnish's Edge Side Includes. When Varnish comes across these, it will load and embed the template we've asked for bypassing the cache for that section. Kevin's original post provides practical examples for this, so I won't repeat them here.

If you're already using {embed} tags for your site the good news is that ESI are basically a drop-in-place replacement. But if your dynamic content is set through snippets or some other method you're likely going to have to refactor your templates a bit.

People using Stash may want to buy Mustash. Mustash enables Varnish cache breaking for websites powered by Stash.

What Else?

In the discussions a couple of interesting use-cases for Varnish came up that go beyond the obvious performance benefits.

One was the ability to cache the entire website while a website upgrade procedure or server maintenance is taking place without any downtime. This would naturally work better for static websites but even most eCommerce sites could comfortably cache the product and category pages up until the checkout process.

Kevin mentioned that because ExpressionEngine doesn't have any advanced publishing workflows built in some companies have taken to using Varnish to preview changes before the public sees them. They do this by visiting the Apache server directly (which might be the same domain on port 8080, for example) and then clearing Varnish's cache once they're happy with the changes.

Or you could add to your VCL a rule to bypass the Varnish cache entirely for users from a certain IP address. That could allow for an editorial team on a website to always see a working version of a site without disrupting the public-facing site.

Do I Need It?

This was something that kept coming up on the Dev Day. John and I spoke afterwards and it came clear that, "you'll know when you'll need it".

That said, if set up correctly, it's not going to do any harm. In fact it's probably going to be beneficial - it protects your site from unexpected spikes in traffic (links from Reddit, HackerNews or similar sites are known to kill sites in seconds) and provides faster load times, which is looking like an increasingly important ranking factor for Google.

It's great knowledge to have, because when the day comes that your site is performing really well you'll benefit from being able to set it up with relative ease.

But do you need it? Probably not. Kevin actually mentioned that currently EllisLab doesn't use it (although he'd like it to) and that there are a bunch of new caching abilities built into recent versions of ExpressionEngine including Memcached and Redis - both faster than the original file/disk read method of caching in EE.