Understanding Automatic Updates in Electron Applications with electron-updater

In recent work on an Electron application, the author shares practical knowledge gained from using electron-updater to handle automatic updates, including full package updates, incremental updates, and partial file updates.

Full update involves downloading a new installer package and reinstalling the app. The process relies on an update.yml file bundled with the installer, which contains the fields version , path , and sha512 . The YAML file can be parsed with the js-yaml library:

const yaml = require('js-yaml');
const fs   = require('fs');

// Get document, or throw exception on error
try {
  const doc = yaml.load(fs.readFileSync('/home/ixti/example.yml', 'utf8'));
  console.log(doc);
} catch (e) {
  console.log(e);
}

Version comparison between the remote and local app is performed with the semver package:

const semver = require('semver');

semver.valid('1.2.3'); // '1.2.3'
semver.valid('a.b.c'); // null
semver.clean('  =v1.2.3   '); // '1.2.3'
semver.satisfies('1.2.3', '1.x || >=2.5.0 || 5.0.0 - 7.2.3'); // true
semver.gt('1.2.3', '9.8.7'); // false
semver.lt('1.2.3', '9.8.7'); // true
semver.minVersion('>=1.0.0'); // '1.0.0'
semver.valid(semver.coerce('v2')); // '2.0.0'
semver.valid(semver.coerce('42.6.7.9.3-alpha')); // '42.6.7'

Incremental update downloads only the changed parts of the installer. electron-updater uses Content‑Defined Chunking (CDC) to split the installer into variable‑size blocks based on a Rabin fingerprint. Each block’s hash and size are recorded in a blockmap file, which is gzip‑compressed. A sample blockmap JSON looks like:

{
  "version": "2",
  "files": [
    {
      "name": "file",
      "offset": 0,
      "checksums": ["VxFZSGxhDYz5FXgMiOUk5oCc"],
      "sizes": [32768]
    }
  ]
}

During an update, the client compares the local and remote blockmaps, determines which blocks differ, and requests only those byte ranges (using range:bytes=x-y ) to reconstruct the new installer.

Partial update targets specific files such as app.asar or app.asar.unpacked . The community project electron-asar-hot-updater detects a new app.asar , downloads it, replaces the existing file, and restarts the app. On Windows, file replacement must be performed by a separate update.exe process because the main process holds a lock on app.asar . Unix‑like systems generally do not have this issue.

The article also discusses gray (canary) release strategies. A stable GUID (stored as stagingUserId ) is generated per user, hashed, and reduced modulo 100 to obtain a number between 0‑100. This number is compared with the stagingPercentage field in update.yml to decide whether a particular user receives the new version, enabling gradual rollout and feedback collection.

In conclusion, the author hopes the summary assists developers in implementing reliable update mechanisms for Electron applications.