Install the CLI
One command per platform; every download verified fail-closed.
tigby is a single static binary. The installer puts it in ~/.local/bin – no root, no package manager – and says so if that directory is not on your PATH.
Linux and macOS
curl -fsSL https://get.tigby.eu | shNeeds glibc 2.27 or newer. On musl (Alpine) the installer refuses with a message rather than installing a binary that cannot run.
To install a specific release rather than the newest one:
curl -fsSL https://get.tigby.eu | TIGBY_VERSION=0.1.0 shThe pinned version is downloaded from its own directory and checked against the SHA256SUMS published there. A version that was never published fails, and nothing is installed.
Windows
The PowerShell installer arrives with the first Release:
irm https://get.tigby.eu/install.ps1 | iexIt will install to %LOCALAPPDATA%\tigby\bin and add that directory to your user PATH. Until then, download tigby-win-x64 from https://get.tigby.eu/v/<version>/, compare it against the SHA256SUMS beside it, and put it somewhere on your PATH yourself.
npm
The npm packages arrive with the first Release:
npx tigbyIt will run the CLI without installing it: tigby on npm carries one platform package per target, resolved through optionalDependencies, with no install script. npm fetches from the npm registry, not from EU infrastructure – get.tigby.eu stays the canonical path.
First run
- macOS: the binary is ad-hoc signed. Installed from the terminal it runs as is; a copy downloaded with a browser carries the quarantine flag – right-click and choose Open once, or run
xattr -d com.apple.quarantine tigby. - Windows: SmartScreen may warn on the first run of an unsigned binary. Choose "More info", then "Run anyway".
Verifying a download
Every Release publishes SHA256SUMS and signs it with minisign.
The shell installer verifies the SHA-256 fail-closed – a machine without a hash tool gets an error, not a skipped check – and the hash it enforces is the tigby-<rid> line of that release's SHA256SUMS, the file the signature covers. v/latest.json says which version is newest and what this target's binary is called; it does not decide what the download must hash to.
The signing key
The minisign public key is published here and in the tigbyhq/keys repository – deliberately not on get.tigby.eu, so the download host cannot vouch for itself. The installer will carry an embedded copy of the same key; this page and that repository are the references to compare it against.
The key appears here with the first Release, and until then no signature is checked. The installer says so when it runs on a machine that has minisign, rather than skipping in silence. What holds today is SHA-256 against a SHA256SUMS served by the download host: a check against a corrupted transfer and against a modified artefact, and not yet a check against a compromised host.
TIGBY_MINISIGN_KEY overrides the embedded key, for testing a release before its key is published. It is never the only way the signature is checked.
Upgrading
tigby upgradeReads the release manifest, verifies the download against the published SHA-256 fail-closed, and replaces the binary in place. A current binary is a no-op.
tigby upgrade checks no signature – the manifest it reads is not signed and the CLI carries no key. To install a release with its signature verified, run the installer above rather than upgrading.
Not on Windows yet. tigby upgrade cannot replace a running tigby.exe: Windows holds the image open, so the replace fails and the command reports an error about file ownership that has nothing to do with the cause. Download the new tigby-win-x64 from https://get.tigby.eu/v/<version>/, check it against the SHA256SUMS beside it, and replace the file yourself while nothing is running it.