# How Adom Bridge updates itself, and what it costs your network Adom Bridge keeps four things current on their own: the Windows app, the bridges, the container CLI and skills package, and the skills folder for local AIs. Each lane is described below, followed by the network math and the safeguards against update traffic ever becoming a problem. ![A high priority update installing in the background, with a heads-up toast](update-high.png) ## Lane 1: the Windows app The app polls one small manifest, `version.json` on the wiki page (about 1.2 KB), on launch and then every 4 hours. Nothing else is fetched unless the manifest names a newer version. When a newer version exists: 1. The signed installer (about 13 MB) is downloaded once and SHA256-verified against the manifest. 2. What happens next depends on your update mode (Settings, Updates): `prompt` (the default) shows a footer banner with Install now / Later; `auto` installs silently; `off` installs nothing. 3. The install runs the NSIS silently and relaunches the app. Since 1.9.175 that relaunch returns to the tray without showing or focusing the window, and when the machine is busy the auto-restart waits for about 15 minutes of idle time first (`update_idle_minutes`). Embedded under Hydrogen, Adom Bridge stages the update and Hydrogen chooses the moment to apply it. Releases carry a priority tier. Normal releases (almost all of them) respect your mode. A high release auto-installs in the background even in `prompt` mode, with a toast saying so. An emergency release, reserved for a defect bad enough to pull from the whole fleet at once, shows a 60 second countdown and force-installs, and is additionally gated on the installer's Authenticode signature (it must be signed by Adom Industries) plus downgrade protection (only a strictly newer version can ever be forced). Even with updates set to `off` the 4-hour manifest check still runs, so an emergency signal can always reach the machine; `off` suppresses installs, not the check. A fleet machine can also be driven remotely: `update_status`, `update_check`, `apply_update`, and `update_set_mode` work over the relay, so a headless box never needs a keyboard to stay current. ## Lane 2: bridges Each bridge updates independently from its own wiki page. Adom Bridge polls every bridge's manifest (a small JSON, a few KB) on launch and every 4 hours, and downloads a bridge's zip only when the published version is newer than the cached one. Installed dependencies a source-only bridge provisioned locally (such as a node bridge's `node_modules`) are preserved across the swap. You can also force a check with `bridge_check_updates` or apply one with `refresh_bridges`. ## Lane 3: the container CLI and skills package Cloud containers install `adom/adom-bridge` with `adom-wiki pkg update`, which fetches the package tarball (about 4 MB) only when the published version is newer. The CLI also runs a once-per-day background sync in containers that installs each connected bridge's own skill package, so a container's skills track whatever bridges the desktop actually has. If the container runs the relay under `serve --supervise`, the watchdog notices a newer CLI binary on disk (a local check, no network) and restarts the relay into it, so an updated CLI takes effect without anyone remembering to restart. ## Lane 4: skills for local AIs On every launch the app copies its bundled skills into `~/.claude/skills` and `~/.codex/skills` for local agents like Claude Desktop. This is a local disk copy from the installer's own files: zero network traffic. One-time downloads are separate from updating: on first launch Adom Bridge may fetch a portable Node and Python for bridges, and the browser bridge may fetch its dedicated Chrome. Those happen once, not on a schedule. ## The network math Steady state, per machine, per day: six manifest checks for the app (about 7 KB total) plus six manifest sweeps across the bridges (tens of KB total). Call it well under 1 MB per machine per day when nothing has been released. This is negligible at any fleet size. The meaningful traffic is release day. When a new app version publishes, every machine downloads the installer once: about 13 MB times the fleet size, naturally spread across the 4-hour polling window because each machine's timer runs on its own schedule. A bridge release behaves the same way with that bridge's zip. A day with many releases multiplies this, which is why routine changes are batched into fewer releases where practical. Safeguards that keep update traffic bounded: - One download per release per machine. The manifest version comparison happens before any download, and a machine already current fetches nothing but the manifest. - SHA256 verification before install, so a corrupt download cannot cause an install-retry storm; a failed forced install backs off after 3 attempts rather than looping. - No peer-to-peer, no push. Every fetch is a client-initiated HTTPS GET to the wiki, which sits behind CDN caching, so release-day load lands on the CDN rather than the origin. - The emergency tier is a manual, deliberate action. A routine release never carries a priority and never overrides anyone's `off`. - WSL activity is quiesced during an update apply, so the restart cannot pile WSL launches onto the update window. The honest concern to watch: many app releases in a single day means the fleet downloads the installer for each of them (the fleet applied roughly eight updates during one heavy development day, about 100 MB per machine). The system tolerates this fine, but batching releases is the cheap lever if fleet size grows into the thousands. ## Where to look when something seems off - The footer version label is clickable and forces a check. - `adom-bridge-cli update_status` shows the current and available versions, the staged state, and the release priority. - `startup.log` next to the exe records every apply and relaunch decision.