Varnish Cache is a web application accelerator also known as a caching HTTP reverse proxy. You install it in front of any server that speaks HTTP and configure it to cache the contents. Varnish Cache is really, really fast. It typically speeds up delivery with a factor of 300 - 1000x, depending on your architecture.
This add-on integrates Varnish into your DDEV project.
ddev add-on get ddev/ddev-varnish
ddev restartNote
Run ddev add-on get ddev/ddev-varnish after changes to name, additional_hostnames, additional_fqdns, or project_tld in .ddev/config.yaml so that .ddev/docker-compose.varnish_extras.yaml is regenerated.
After installation, make sure to commit the .ddev directory to version control.
The Varnish service inserts itself between ddev-router and the web container, so that calls to the web container are routed through Varnish first. The docker-compose.varnish.yaml installs Varnish and uses the default domain as its own host name.
A docker-compose.varnish_extras.yaml file is generated on install which replaces the VIRTUAL_HOST variable of the web container with a sub-domain of the website URL. For example, mysite.ddev.site, would be accessible via Varnish on mysite.ddev.site and directly on novarnish.mysite.ddev.site.
If you use a project_tld other than ddev.site or additional_fqdns DDEV will help add hosts entries for the hostnames automagically; however, you'll need to add entries for the novarnish.* sub-domains yourself, e.g. ddev hostname novarnish.testaddfqdn.random.tld 127.0.0.1.
This add-on also providers several helper commands. These helpers allow developers to run Varnish commands from the host, however, the commands are actually run inside the Varnish container.
| Command | Description |
|---|---|
ddev varnishd |
Varnish-cli |
ddev varnishadm |
Control a running Varnish instance |
ddev varnishhist |
Display Varnish request histogram |
ddev varnishlog |
Display Varnish logs |
ddev varnishncsa |
Display Varnish logs in Apache / NCSA combined log format |
ddev varnishstat |
Display Varnish Cache statistics |
ddev varnishtest |
Test program for Varnish |
ddev varnishtop |
Display Varnish log entry ranking |
ddev logs -s varnish |
Check Varnish logs |
See The Varnish Reference Manual for more information about the commands, their flags, and their arguments.
You may want to edit the .ddev/varnish/default.vcl to meet your needs. Remember to remove #ddev-generated from the file if you want your changes to the file preserved.
To change the Docker image:
ddev dotenv set .ddev/.env.varnish --varnish-docker-image=varnish:6.0
ddev add-on get ddev/ddev-varnish
ddev restartMake sure to commit the .ddev/.env.varnish file to version control.
All customization options (use with caution):
| Variable | Flag | Default |
|---|---|---|
VARNISH_DOCKER_IMAGE |
--varnish-docker-image |
varnish:6.0 |
VARNISH_VARNISHD_PARAMS |
--varnish-varnishd-params |
-p http_max_hdr=1000 -p http_resp_hdr_len=1M -p http_resp_size=2M -p workspace_backend=3M -p workspace_client=3M |
Allows modifying the varnish startup parameters.
The provided defaults are set deliberately higher than what varnish usually defines. The reason for this is that in development environments it is not uncommon to have larger payloads either in HTML or HTTP-Headers. E.g. Drupals theme debugging or cache tag handling. Without increasing these limits, one might encounter hard to isolate errors like the following form nginx:
2025/07/15 09:01:01 [info] 1549#1549: *259 writev() failed (32: Broken pipe) while sending to client, client: 172.20.0.6, server: , request: "GET /en HTTP/1.1", upstream: "fastcgi://unix:/run/php-fpm.sock:", host: "myproject.ddev.site"
Maintained by @jedubois and the DDEV team
Based on the original ddev-contrib recipe pioneered by rikwillems