tapid upgrade
Verify a published release and replace the Tapid executable.
Version scope
tapid upgrade is available starting with published v0.0.10. Clients through v0.0.9 do not expose the command; rerun the public installer from Getting started to replace those installations.
Syntax
Inspect and verify the selected release before replacing the executable:
--dry-run can contact release services and download verification inputs. It does not replace the destination executable. A normal upgrade stages replacement after validating the selected archive. Network recovery can use a last-known-good cached release; recovery is not evidence that the latest version was checked.
Published v0.0.13 discovery
Default discovery reads the release record at https://tapid.dev/releases/v1/latest.tsv. The client independently authenticates its .sig sidecar against the embedded production keyring, then validates archive size, SHA-256 and archive contents before staging replacement. Default discovery does not fall back to the GitHub API.
| Option | Purpose |
|---|---|
--dry-run | Inspect and verify without replacing the executable. |
--destination PATH | Select the executable path instead of the running binary. |
--release-url HTTPS_URL | Select another release-record address. TAPID_RELEASE_RECORD_URL is the environment override. |
--endpoint HTTPS_URL | Use the separate historical signed-discovery protocol; repeat to try endpoints in order. |
--keyring PATH | Supply a trusted keyring for controlled configurations. |
--endpoint cannot be combined with --release-url. A release-record override also cannot be combined with --keyring. Do not change discovery or trust configuration to bypass verification errors.
When verified executable bytes already match, Tapid reports that it is up to date and leaves them unchanged. It still downloads and verifies before comparing. Cached recovery explicitly reports when it could not check the latest release. Durable version/digest state rejects downgrades and different executable bytes at the same version; it does not resist hostile local modification.
Clients through v0.0.10 retain historical discovery behavior. v0.0.10 can use canonical GitHub checksums when its default signed endpoints are unavailable. Checksum-only verification shares the provider trust boundary. Neither the newer release-record signature nor archive checks establish platform code signing or package publisher provenance.
For existing managed installations, use tapid upgrade. Installers from v0.0.12 onward prevent historical scripts from replacing an installation with different bytes or bypassing managed state. Read Getting started for fresh installation.
Common failures
Unsupported platforms, unavailable discovery without usable recovery data, invalid metadata, mismatched archives, and replacement failures stop the operation. Do not change endpoints or trust roots to bypass a verification failure.
See the public release-distribution procedure for operational details.