Upgrading

Weaver has no in-app upgrade. Each install upgrades the way it was installed. Before any of them, export a backup from Settings → Backup and leave the data directory in place: it holds the database, which the new version migrates on first start.

Which Path Applies

Install	Upgrade with
Docker, Podman, Unraid	Pull the new image and recreate the container
Homebrew	`brew upgrade weaver-usenet`
Winget	`winget upgrade`
MSI from GitHub	Run the new MSI
macOS desktop app	Open the new DMG and replace the app
Portable archive	Stop, replace the binary, start

Keep one package manager per Windows machine. Do not run a GitHub MSI over a Winget install or the reverse.

Docker

docker compose pull
docker compose up -d

Container images set the bind address themselves, so nothing else changes. Check Logs for migration messages after the restart.

Homebrew

brew update
brew upgrade weaver-usenet
brew services restart weaver-usenet

For a same-version packaging fix, use brew update --force then brew reinstall weaver-usenet.

Windows

The MSI installs per-machine, so both paths need administrator rights.

Right-click the tray icon and choose Exit.
Run winget upgrade --id ScryerMedia.Weaver --exact from an administrator PowerShell, or run the new MSI from GitHub.
Launch Weaver from the Start Menu. Winget installs are silent and silent installs never start the tray. Running the MSI interactively starts it for you.
Open the tray menu and turn Start at sign-in back on if you used it. The installer removes the previous version’s startup entry during the upgrade.

The data directory under %LOCALAPPDATA%\weaver is untouched. See Winget.

macOS Desktop App

Choose Quit Weaver from the menu bar icon, open the new DMG, and drag Weaver to Applications, replacing the old copy. A release that is not notarized needs the right-click Open dance once more on first launch.

Portable Binaries

Stop the process, replace the binary, and start it with the same --config path and flags.

Installs That Predate 0.12.0

Upgrading to 0.12.0 keeps an existing install on its older access settings, so nothing changes about who gets in. Installs created on 0.12.0 or later use a simpler model. Every browser signs in, trusted proxies are set in Settings → Security, and hostnames don’t need to be listed. The exception is a new install started with WEAVER_TRUSTED_CIDRS but without WEAVER_ACCESS_MODE=authenticated, which uses the older settings too.

While an install stays on the older settings, it is asked once, on the first open after upgrading: login for every browser, login except your local network, or no login. Where the bind address is still editable it also asks whether Weaver should answer beyond this machine. Keep my current setup preserves pre-upgrade behavior exactly. Environment-managed deployments are never asked. WEAVER_TRUSTED_CIDRS pins the browser-access policy and WEAVER_HTTP_BIND_ADDRESS pins the address. Everything the prompt covers stays editable in Settings → Security.

To move an existing install to the 0.12.0 model, set WEAVER_ACCESS_MODE=authenticated and restart. Your login and API keys carry over, and every browser signs in again. Networks that used to skip the login now only decide where browsers can be remembered. Once an install with a login has started this way, the move is permanent and the variable can be removed, unless WEAVER_TRUSTED_CIDRS stays set. See Security And Access.

After Upgrading

Confirm the version under System Info.
Check Logs for migration or startup errors.
Check Monitoring for queue and bandwidth cap state.
If a reverse proxy is in front, confirm you can still sign in through it. See Reverse Proxy.
Confirm integrations still authenticate. API keys survive upgrades.

Backup And Restore explains what a backup contains.
Desktop App And Binaries describes the tray and portable installs.