SoarStarter

Auto-Updates for Desktop Apps: How the Electron and Tauri Templates Do It

Desktop apps have to update themselves. Here's the signed static-feed model both our desktop templates use — electron-updater and tauri-plugin-updater — and why signing is non-negotiable.

SoarStarter Team

A web app updates when you deploy. A desktop app is already installed on the user's machine, so it has to update itself — download a new version, verify it's really yours, and swap itself out. Get this wrong and users are either stuck on old builds forever or, worse, tricked into installing a tampered one.

Both SoarStarter desktop templates — Electron and Tauri — ship auto-update built in, using the same overall shape: a signed, static update feed with no update server to run. Here's how each does it and what the two agree on.

The shared model: static feeds, no server

Neither template requires you to run an update backend. Both publish a set of static files (installers plus a small metadata file) to any host — object storage, a CDN, GitHub Releases — and the app polls that metadata to discover new versions. That's the whole "server": files behind a URL.

Both are also flag-gated and on by default, and both share a deliberate UX rule: a feed failure never blocks the app. If the update check can't reach the feed, the error is captured as a status, not thrown — the user keeps using the app. That's the correct default for something that runs on every launch.

Electron: electron-updater + a generic feed

The Electron template uses electron-updater against a generic provider:

  • electron-builder.yml declares a generic publish provider whose URL comes from electron-builder.env.
  • Each build publishes platform installers plus a metadata file — on Windows, latest.yml alongside the NSIS -setup.exe and its .blockmap (the blockmap enables differential downloads, so updates ship only changed chunks).
  • electron-updater reads latest*.yml to discover whether a newer version exists, then downloads and stages it.

Release flow: bump the version, build signed installers per platform (pnpm build:mac|win|linux, or in CI), upload them to the feed, and verify. Tag a release v* and the template's CI matrix-builds signed/notarized installers for all three platforms.

Tauri: tauri-plugin-updater + minisign

The Tauri template uses tauri-plugin-updater against a static feed, with a stronger cryptographic guarantee baked in:

  • The feed lives at ${UPDATE_SERVER_URL}/${channel}/latest.json.
  • latest.json describes the version, notes, publication time, and a per-platform download URL with an inline minisign signature.
  • Tauri verifies that signature against your public key before installing — a build the plugin can't cryptographically verify is refused.

Release flow: keep TAURI_SIGNING_PRIVATE_KEY (and its password) only in release CI; tagging v* produces a draft GitHub Release with installers, signatures, and latest.json attached. Verify the hosted layout has latest.json and every referenced URL present.

Signing is not optional

Both templates say the same thing loudly, because it's the part people skip and regret:

  • macOS — updates require signed and notarized builds. Gatekeeper rejects an unsigned replacement, so an unsigned app literally cannot auto-update on macOS.
  • Windows — signing is strongly recommended; unsigned updates trip SmartScreen warnings that tank install completion.

Tauri's minisign layer verifies the update payload's authenticity; OS code signing verifies the app's — you want both. Set up signing before you rely on auto-update, not after your first user reports a broken installer.

Which model to prefer

They're more alike than different — static feed, no server, signing required, non-blocking UI. The distinctions:

  • Electron leans on the mature electron-updater ecosystem and blockmap differential downloads; the generic-feed config is minimal.
  • Tauri bakes minisign verification into the feed itself, so update authenticity is enforced by the updater regardless of transport.

If you're choosing between the two templates on other grounds, auto-update shouldn't be the deciding factor — both are solved. (For the broader Electron-vs-Tauri trade-offs, see our comparison.) The Electron auto-update docs and Tauri auto-update docs cover the feed layout, signing, and release flow for each.