Skip to content

Configuring a CDN

Content delivery networks (CDNs) are a good way to speed up delivery of your app. They're especially important when using aggressive updates, as in that mode your app's startup time depends on how fast the update check can complete.

CDN requirements

Your CDN must support HTTP range requests. This is required for Windows and installs will fail without this support. Any modern CDN will support this.

Your CDN should not use HTTP redirects to serve files. Although this can work, it slows down installs and updates on Windows.

Serving configuration

You must expose all the files generated by conveyor make site on your server, including You can exclude the generated download.html and the icon file if you don't use those. Additionally, you should leave old versions of your Mac app on the server.

This is required because Conveyor will download data from your during package builds and as part of update checks. This enables:

  1. macOS delta patches. Conveyor will check to work out what the version numbers of the last app.mac.deltas versions are of your app so it can download the old versions to compute delta patches, if they aren't found in your disk cache.
  2. Overwrite prevention. Update systems can break in obscure ways if you overwrite an already published version number with different files. Conveyor checks your site to ensure this isn't accidentally happening.
  3. Package identity change handling. Windows gets unhappy and requires the escape hatch mechanism if your package identity changes (e.g. product rebrand, new company name in the certificate). To detect this case the file is read to compare the signing identity of the already published versions against the local signing certificate.
  4. Backwards compatibility. Sometimes the way packages are generated needs to be consistent with prior versions across Conveyor upgrades. The site is checked to work out what was previously deployed.

See Remote Site Checks for more information.


conveyor make site generates two kinds of file:

  1. Volatile. These should not be cached by your CDN, as they are small and change.
  2. Stable. These can be cached indefinitely by your CDN, as they are large and immutable.

Stable files always have a version number in them. Every other kind of file is volatile. Here's a list of globs that match volatile files:


When doing uploads the stable files should go first. When they are uploaded and properly replicated the volatile files can be uploaded. This prevents metadata files being served that point to data files that aren't available yet. If you use the conveyor make copied-site task to upload files for you then upload ordering is handled for you.