# Install an update URL: /deploy/upgrades Install a new Foxborne release from its signed bundle. Foxborne checks the signature, the bill of materials and the database migration before anything installs, then schedules the install for the maintenance window. Updates reach a Foxborne deployment only as signed bundles, never as downloads. An admin brings the bundle in and starts the install from **Hosting**. Foxborne checks the bundle before anything installs, and the workers restart one at a time, so there is no downtime. ## Before you start [#before-you-start] * You need the **Admin** role. Admins manage hosting, keys and access. * The release's `.fxb` bundle is inside your network. In an air-gapped enclave, it arrives on media your process approves. * You have read the release's entry in [Release notes](/release-notes). ## Install the update [#install-the-update] Each release is one signed file with its software bill of materials. Nothing is downloaded: your administrator brings the file in, under your own transfer process. Go to **Hosting** and select **Install an update** in the page header, or **Install** on the **Updates** panel. Both open the same dialog, subtitled **Updates are signed bundles. Nothing is downloaded; your administrator brings the file in.** The dialog shows the bundle as a file card, `foxborne-1.4.3.fxb` in the example, and starts checking it. Foxborne runs four checks in turn and marks each one as it passes. | Check | What it tells you | Example line | | -------------------------------- | ---------------------------------------------------------------------------- | ------------------------------------------------------------ | | **Read bundle** | The file's name and size | foxborne-1.4.3.fxb, 412 MB. | | **Check signature** | Who signed the bundle | Signed by the Foxborne release key 7C1E 4B90 3A2F 9A42. | | **Check the bill of materials** | The SPDX version, the component count and any known critical vulnerabilities | SPDX 2.3, 418 components, no known critical vulnerabilities. | | **Check the database migration** | What the release changes in PostgreSQL | Two additive migrations, no data rewritten. | The install button, **Install 1.4.3** in the example, stays unavailable until all four checks finish. Nothing installs if the signature does not match the Foxborne release key. The dialog's footer reads **Downtime: none. Workers restart one at a time.** Select the install button to confirm. Foxborne schedules the update for the maintenance window and says when it will run. In the example, the message reads **1.4.3 will install in the maintenance window tonight at 02:00 UTC**. The audit log records the step as **Scheduled update** on `1.4.3`, with the detail **Signature and SBOM verified**. ## Check the result [#check-the-result] The deployment keeps running the installed version until the maintenance window. Afterwards, open **Hosting**: * **Version** in the summary strip shows the new release with **Signature verified**. The status bar shows **Foxborne** and the version on every screen. * The **Updates** panel shows the version and date under **Installed** and the release key under **Signed by**. **Bill of materials** gives the SPDX version and component count, **stored with the release**. * The history under it lists each release with its note, the admin who installed it and the date. * The audit log records the installation. In the example dataset, 1.4.2 appears as **Installed update** with the detail **Signature verified, SBOM stored**. The update history in the example dataset reads: | Version | Note | Installed | | ------- | ----------------------------------------------- | ----------- | | 1.4.2 | Parser fixes for PX4 v1.16 rover topics | 12 Sep 2026 | | 1.4.1 | Receive log latency estimates from SYSTEM\_TIME | 1 Sep 2026 | | 1.4.0 | Manual clock alignment from matching events | 15 Aug 2026 | ## Update the collectors [#update-the-collectors] Collectors update separately, from your deployment. Under **Sources**, **Vehicle collectors**, a row on an older collector shows **No SYSTEM\_TIME** beside its version and offers **Update**. The example has two vehicles on 0.7.3. Select **Update**, then **Schedule update** in the dialog. The vehicle downloads collector 0.8.1 from your deployment the next time it is on the ground and online. The audit log records **Scheduled collector update** with the versions, for example **0.7.3 to 0.8.1**. Version 0.8.1 records `SYSTEM_TIME` pairs, which give companion evidence a shared anchor with the flight log. ## Troubleshoot [#troubleshoot] **The install button stays unavailable.** It waits for all four checks. Each one appears in turn with a check mark, and the button becomes available after the last. **The signature does not match.** Nothing installs. Foxborne installs only bundles signed with the Foxborne release key, so a damaged or altered file stops at this check. Bring in a fresh copy of the bundle. **The version has not changed yet.** Confirming schedules the install, which runs in the maintenance window. Until then, **Hosting** shows the version already installed. ## Next [#next] * [Release signing and SBOM](/security/release-signing) explains the release key and the bill of materials. * [Release notes](/release-notes) lists what each version changed. * [Air-gapped installation and updates](/deploy/air-gapped) covers carrying bundles into an enclave. * [Monitor a deployment](/deploy/operations) covers the other **Hosting** panels.