# tapid upgrade

Source: https://tapid.dev/docs/commands/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](https://tapid.dev/docs-markdown/getting-started/content.md) to replace those installations.

## Syntax

```text
tapid upgrade [OPTIONS]
```

Inspect and verify the selected release before replacing the executable:

```bash
$ tapid upgrade --dry-run
$ tapid upgrade
$ tapid --version
```

`--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](https://tapid.dev/docs-markdown/getting-started/content.md) 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](https://github.com/LimeTip/tapid/blob/v0.0.13/docs/release-distribution.md) for operational details.