Varnish offers a multitude of modules that extend standard VCL capabilities for specific use cases and improve the overall user experience. These modules are written in C, and we call them VMODs for short. You can see the full list here.

We’re very excited to introduce Varnish Controller to the world! Our new administration console for managing Varnish clusters, the Varnish Controller makes Varnish tools and processes accessible from an intuitive user interface. It’s built from the ground up to make deploying and maintaining Varnish easier and faster, with tools for autoscaling, updating edge logic, load balancing and more.

Varnish is a caching server, and a great one at that, that much we already know. But what about the content you don't want to cache? For example, those shopping cart requests and other completely uncacheable API calls?

We can of course handle it, but we've got to be wary of the sirens of the cargo cult because you will often see something like this on the internet:

sub vcl_backend_response {
    # check if the backend response header named
    # "cache-control" contains the word "private"
    if (beresp.http.cache-control ~ "private") {
        # if so, don't cache by limiting the Time-To-Live
        # period to 0 second
        set beresp.ttl = 0s;
    }
}

This is both pretty intuitive, and also very wrong. In this post, we'll explore why it's a bad idea, how to do better, and along the way, we'll try to shine some light on a couple of lesser known features of Varnish.

If you’re familiar at all with Varnish, you know it improves content delivery performance by storing a copy of your content in cache, and every request thereafter is fulfilled by the cached content.