Updates

What happens on first launch?

Varve asks whether it may periodically check for a newer version. Choosing Not now keeps update checks manual. Choosing automatic checks lets Varve look for updates on a schedule and notify you when one is available. You can change or revoke this choice in Settings > Updates.

Checking for an update is separate from downloading and installing it. Even when automatic downloads are enabled, installation remains a separate action. An optional install-on-quit preference is available only when you explicitly enable it, and Varve routes installation through its save/quit protection so unsaved work is not silently discarded.

What information is sent?

An update check contacts Varve's HTTPS release endpoint with the information needed to select a compatible feed: your current version, platform, architecture, and update channel. It does not send an account, document contents, filenames, filesystem paths, project data, or a device identifier. The endpoint still receives ordinary network information such as an IP address, as any HTTPS server does; see the privacy policy for the broader data practices.

Which installs can update in the app?

• Linux AppImage: supported only when the running AppImage is in a writable location and can replace itself.
• Windows NSIS: the updater artifact is verified before installation, which happens only after you approve the download and install action.
• macOS: supported for a writable app installed in Applications. A mounted DMG or Gatekeeper-translocated copy must be moved into Applications first.

Availability is determined by the installed package, not only by the operating system. Development builds, unsupported architectures, and builds that fail their runtime capability checks remain manual-only.

Which installs stay manual?

• Debian and RPM packages: the package manager owns the installed files, so update them through your configured package source or the download page.
• Read-only, mounted, or extracted copies: download a new release and replace the copy using the installation method for that build.
• Web and development builds: use the relevant deployment or source workflow; they do not participate in the desktop update feed.

How is an update verified?

Release feeds are published only after the release workflow has built the artifacts and verified the updater signatures, platform trust reports, checksums, and SBOMs. The installed app contains the updater public key and verifies the downloaded update before it can become ready to install. A failed or interrupted verification leaves the current installation in place.

If an update is unavailable, fails verification, or cannot replace the current package, Varve explains the limitation and leaves the release notes and manual download path available.

Downloading and installing

A download can be cancelled from Settings while it is in progress or while the download is being verified; a cancelled download is never installed. Even after a verified update is ready, installation happens only when you choose Install and Restart(or when the optional install-on-quit preference is enabled and you quit Varve). Before Varve restarts, it runs the normal save/close workflow for every open document — unsaved design work is never discarded to apply an update, and cancelling the save prompt also cancels the restart.

If you use several windows, they share one update state: a download started in one window is shown in the others, and a second window will not start its own download of the same update.

Release channels

Each build is compiled for exactly one channel. A stable build checks only the stable feed, a beta build checks only the beta feed, and neither can be redirected to another channel. Stable builds never receive alpha, beta, or nightly releases. Channel switching is a deliberate reinstall from the download page; an in-app update never silently changes channels or downgrades the application.