Running Varnish on Fly


  • Introduction
    • What is Varnish? Why use it?
    • How does Varnish work? - Nothing super in-depth, but I think it’s important to understand how Varnish works at a high level to use it properly
    • Why host Varnish on the Edge with Fly? - Performance - not only do you get the performance benefits of Varnish, you also lower latency by serving it on the edge.
  • How to deploy Varnish to Fly
    • Creating a new Fly App
    • Setting up the Dockerfile (based on
    • Creating a Varnish config file (VCL)
    • Connecting Varnish to a backend service - will probably use an open API from this list
    • Benchmarking the performance improvement by going through Varnish - compare the original API to a call to Varnish on Fly
  • Conclusion

This one sounds amazing. I want to do a big “image service + caching” example with nginx, but it would be interesting to combine it with varnish as well.

1 Like

This is a great outline - I’d add a few more things:

  • How to protect your backend so it is only available through Varnish, but yet retain the ability for you to access the backend to debug (via a custom access header)
  • How to monitor & “warm up” your Varnish install during the deploy process
    I had a project where I used Varnish and due to the load (site was on TV, so immediate high load) I had to write a spider to warm up the cache a bit.

Just some ideas!

We’ve got this working locally in Docker (using a an Express app hosted on Fly as the backend), but when we try to run the Varnish image on Fly, we’re getting this error:

Running: docker-varnish-entrypoint varnishd -F -f /etc/varnish/default.vcl as root
Error: Could not resolve -T argument to address
Name or service not known
(-? gives usage)
reboot: Restarting system

Here’s the whole Varnish, Dockerfile, etc. from the writer:

Does this seem like a Fly issue? If so, any ideas how we might debug it?

It’s saying how to debug it - The -T flag on varnish opens a management console.

I’m assuming it can’t resolve the address of the backend server at that point. Try the default.vcf with and IP address first and see what the results are like.

Thanks @Codepope

I did try with IP address only, but the same error persists.

Curious: when would you use Varnish rather than Nginx? What’s their respective strengths?

@Gaurav I got the same error first, then I realized that Varnish runs on port 80 in the container. This means you need to update the internal_port in your fly.toml file:


  internal_port = 80

Now it’s getting stuck at the building fs... step, but that might be another issue.

@ben Varnish is typically used for caching an entire web page as static HTML. Nginx usually sits behind it and serves dynamic content when Varnish doesn’t serve the static content.


Ok, that still didn’t work. I’m getting the same errors as @Gaurav on Fly, but no errors when I run it locally.

Is it possible this is some kind of network permission problem? Maybe Varnish can’t access the outside network? Is there a good way to test this?

I think this has something to do with the default varnish options, the -T control socket, and the Fly VM. I’m not sure if there’s a simpler way to start Varnish, but I’d try running it with minimal options. There should be a way to disable -T and override all its defaults by specifying a command like this:

CMD ["/usr/sbin/varnishd", "-F", "-f", "/etc/varnish/default.vcl"]

@kurt thank you!

You turned me onto the -T flag, which you have to set to none in order to disable the admin. I ended up adding this to my Dockerfile and it works now:

CMD ["/usr/sbin/varnishd", "-F", "-f", "/etc/varnish/default.vcl", "-T", "none"]

@Gaurav let me know if you have any further questions.

1 Like

@Gaurav finished the article this week and I did a little cleanup before transferring it into the fly-examples repo:

So you can credit him with the article, Gaurav’s GitHub account is here:

1 Like