Varnish Software Blog

Varnish Cache: LTS, TLS and other goodies

Written by Guillaume Quintard | 4/17/26 9:49 PM

In the last few weeks, a lot has happened surrounding the release of Varnish 9.0. You’ve probably learned about HTTPS support, but there’s more! Let’s go over what has changed, what hasn’t, and what will, plus a tiny teaser about what’s cooking.

TLS, sweet in-core TLS

Are you annoyed with having to run a side-car to terminate TLS? For years, this was the suggested solution, to keep Varnish a “pure” HTTP server. Well, it’s 2026 and HTTPS is the norm pretty much everywhere. Varnish Enterprise introduced in-core TLS years ago, allowing Varnish to terminate TLS directly, and Varnish Cache is finally following suit! We’ve reused the Hitch config file and syntax, here’s how it looks:

$ cat /etc/varnish/tls.conf frontend = { host = "" port = "443" } pem-file = "/etc/varnish/certs/mycert.pem" $ varnishd -f /etc/varnish/default.vcl -a :80 -A etc/varnish/tls.conf

(more information on varnish.org!)

Not only that, but you can also connect to HTTPS backends! Look how easy that is:

backend default { .host = "srv1.internal.example.com"; .port = "443"; .ssl = 1; # Turn on SSL support }

This is made possible by open-sourcing the code that we’ve been running for years in Varnish Enterprise, so we are pretty confident that it's solid. Hardcore Varnish users have long since learned about “the sandwich”, in which you surround Varnish with HAProxy/Nginx/hitch and there is almost nothing wrong about that. Apart from ergonomics and performance.

Usability-wise, it’s cumbersome to run two or three processes when one can do the trick, especially in this age of virtualization that really insists on mono-process containers. The speed aspect may not impact you that much, as a TLS terminator talking to Varnish via UDS will happily take you to 50-100Gbps, but then the back-and-forth between the two tools becomes just too costly. We wouldn’t have reached 1.5Tbps per server without in-core TLS

And there are more cool things on the horizon too, for example with custom certificates for backends, or even with OpenSSL 4 just being released.

A new Long Term Support version has landed

Varnish releases happen twice a year, in March and September, with each release being supported for one year. This makes sure we can iterate fast, but it can be too fast for some users who would need to lock their software versions. This is why we have the Long Term Support (LTS) series, which is supported for years. This means no new features, just bug and security fixes, guaranteeing predictability in highly critical environments.

The previous LTS series was 6.0 LTS, released initially in…2018??? It’s getting quite old, and it’s time for a replacement[1]. That replacement is of course the 9.0 series which is a strong starting point, with “new” features but also great stability baked in. The big difference with its predecessor though is that we won’t keep it around for that long. We haven’t set a plan in stone, but a safe assessment is for the LTS “contract” to last 2 to 3 years, as it provides stability to users without depriving them from the cool new features for too long.

Unfortunately, this means we need to say goodbye to 6.0 LTS, but fear not: we’re going to support it until April 2027, so you still have plenty of time to switch!

Not just the core

Varnish is an amazing swiss army knife when it comes to HTTP, but its strength also comes from how extensible it is. VMODs augment your VCL capabilities by adding header filtering, crypto (security, not Bitcoin!) functions or dynamic backends. These VMODs can live in the Varnish core repository, but anyone can create one (in C, or in Rust) and share it with the world.

The problem? You normally need to download, compile and install those modules yourself, which isn’t super ergonomic. This is why we do a couple of things to alleviate the pain.

First, we curate a list of useful VMODs we like. They are not necessarily ours, but we know the authors and trust them. Second, we package them for deb and rpm distribution using this repository. Every time there’s a new Varnish or VMOD version, we rebuild the whole suite[2] and publish it, making it very easy to install Varnish with a comfortable suite of tools. I mean, look at this:

curl -Ls https://packages.varnish-software.com/varnish/bootstrap-deb.sh | sh apt-get install -y varnish vmod-reqwest

That’s easy, right? You can of course find more details on varnish.org.

And if you prefer docker images, we got you covered with the official dockerhub images. This hasn’t changed much, we’ve been packaging them for years, however I[2] have made some adjustments:

  • The images are now only based on Debian, Alpine has been dropped as we were seeing some weird memory behaviors

  • All the curated vmods are installed by default, using the packages we built, as mentioned before

  • More configurability via environment variables

  • Thanks to vmod-fileserver you can use Varnish to serve files from disk

  • Most importantly, the welcome page is now actually welcoming:

And of course, we have Helm Charts! I’m quite excited about this one because now that Varnish Cache has TLS support, it’s going to be easier to merge and reuse code from the Varnish Enterprise’s charts. I’m an engineer, after all, I love refactorings that remove code!

Not done yet

There are a few things I haven’t mentioned just yet, like varnishlog-json, but I will talk about it more extensively in an upcoming post about observability (it’s pretty cool, stay tuned), so for now: hush.

Anyway, as you can tell, we are reinvesting massively into open-source and things are moving fast, but we’re a small team and we’d love your support and contributions. We have a selection of “good first issues” notably on varnish-rs (the rust bindings for vmods)! But if you have any itch to scratch in particular, would like to help in general or you just want to say hi, join us on discord!

[1]: vmods must run on the same Varnish version they were compiled against.
[2]: Yup, me personally, don’t blame anyone else!