Improving deployment times for large sites

TL;DR
We now only upload changed files to our edge infrastructure, making the deployment step considerably faster for large sites. Also, redundant builds are now automatically canceled in order to avoid unneccessary build minute usage.

Introduction

For all of you with large sites, I have some good news: deployment times are now much faster! Statichost.eu started out as a simple static site hosting platform for my own needs - having a trustworthy place to host my own sites (and those of my clients). Most sites were built using Hugo, which is generally very very very fast. Most were also blogs or marketing sites, i.e. at most a hundred or so pages. More importantly, nothing media-heavy.

Nowadays statichost.eu hosts a wide variety of sites - there are journalistic publications (still waiting for the first true news site…), data sets of legal documents, sites with concert recordings, sites with video backgrounds, you name it. Some small, but some actually quite large.

Anyway, long intro to how the only constant is change. What didn’t change, however, was how the public files for a site were uploaded to our web servers. Take the public files, compress them, and send this to the servers. Simple and robust. But not very effective, indeed not ideal at all for large sites…

New feature: Differential Uploads, i.e. upload only changed files

When deploying large sites, a significant challenge is the time and bandwidth consumed by transferring the entire public folder to the server. This is especially painful when most of the content hasn’t changed between builds. To solve this, we’ve introduced differential uploads:

Only files that actually changed between builds are uploaded to the servers. Identical files are re-used from the previous build.

This feature is a game changer for large sites, as it significantly reduces deployment time, especially when only a few assets have changed. Sites with heavy traffic or complex asset structures will benefit the most from the reduced bandwidth usage during deployment and thus the faster deployment cycles.

Quality-of-life improvement: Canceling Builds in the Waiting State

In a high-traffic scenario where multiple builds are triggered (e.g. when editing a site that is configured to build on each modification), it can be wasteful to run every queued build when only the latest version matters. To address this, we’ve implemented logic to cancel any builds waiting in the queue when a new build is requested. The logic ensures that:

Active builds continue uninterrupted. Queued builds are cancelled when a more recent build is requested.

This feature is particularly useful for large sites or those with frequent updates. By cancelling redundant builds, it reduces the number of unnecessary deployments, saving both build minutes for you and server resources for me. Only the most recent build is deployed, ensuring that users always get the freshest content as quickly as possible.

Why These Features Matter

For large sites and sites experiencing frequent builds — such as those that auto-deploy on content updates — these features improve both scalability and resource efficiency. Whether you’re running a large, content-heavy site or one that needs to handle many build triggers, these optimizations ensure smoother deployments, reduced waiting times, and lower usage of build minutes.