We expose the raw VCL, in the browser, for the user to customise, save, and deploy just as the user could if they managed their own Varnish instance. This approach is also key to honouring another section.io mantra - “It’s just Varnish”.

Unfortunately, our original implementation differed from normal Varnish usage in an important way: deploying broken VCL to any typical Varnish instance would be rejected and Varnish would continue to operate with the last known good configuration. However section.io’s Varnish instances would instead lose the last known good configuration and begin serving an error response for all requests.

How Did This Happen?

This difference in handling broken configurations was a by-product of ensuring that the committed files at tip of the repository branch (eg Production) should represent the active configuration of the reverse-proxies handling live traffic. The intent was to reduce the conceptual complexity that would arise from having the most recent commit show one state whilst needing another branch (or tag) to track the state that was last successfully deployed.

This behaviour, while not helping the chance of breaking your site through web-based VCL editing, has always been mitigated by section.io’s recommended local development experience. In local development, VCL changes can be tested, not only to ensure correct syntax, but also to confirm that the actual impact on your site’s behaviour is what you had intended, and tested against the same Varnish version as used in production.

We have wanted to improve upon this situation for a while, to make section.io even easier and safer to use with confidence. Now we have.

A Better Experience

The platform now performs Varnish VCL validation when saving changes made in the Aperture portal web-based editor and when pushing commits from your local development git workspace. This means that you cannot save broken configuration to your application repository that might have previously resulted in serving error pages to your visitors.

For those with a technical interest, this validation is implemented by passing your desired configuration changes to a duplicate Docker container of the same Varnish proxy image that is used to handle your live traffic. This provides high confidence that the configuration is valid in the context of your specific Varnish version and its settings and available modules.

While we still strongly encourage implementing and testing changes in a development environment before promoting them through to Production, you can now also make quick changes in the browser without fear of accidentally forgetting a semicolon.