VCL or "Varnish Configuration Language" is an absolutely brilliant idea, which I may have said once or twice already, but it can be a bit much to wrap your head around the first time you approach it, and the built-in VCL notion is an extra curveball. So today, we sit down and tackle this.

We'll avoid examples, long descriptions and overly complex details to focus on the high-level and almost philosophical concepts governing the VCL. Let's do this!

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.