Install

Get loot

One command. The installer detects your platform, downloads the release archive from dl.millerbyte.com, unpacks it to ~/.loot/bin, and puts it on your PATH.

This is a public alpha: the tool will change, your work is not at risk.

Your repo opens in every later loot. Every stored artifact carries a version that is checked on read, so a newer loot refuses rather than misreading. The one direction that breaks is backwards — don't run an older loot against a repo a newer one has written.
Commands and printed output will change without notice. Verbs, flags and human-readable text are all in flux. Where a verb offers --porcelain or --json — its line in loot --help says so — that output is a versioned contract: column order and status characters change only when the contract number changes, and every --json response carries that number. Parse by position; the values inside a column can gain entries without a bump.
Anything that leaves your machine is experimental. Nothing leaves it unless you ask: every destination loot contacts is one you configured. What you put on a relay or a forge is a demonstration, not a service. Hosted data may be reset without warning — keep nothing there you cannot lose.

Alpha builds are numbered v0.5.0-alpha.N. loot --version prints the one you have; quote it in any bug report.

curl -sSf https://loot.millerbyte.com/install.sh | sh

Then open a fresh shell and run loot --version — the one-liner installs the newest build for your platform, so what it prints depends on which one you're on: loot 0.4.24 on Windows and Linux, loot 0.4.14 on macOS right now. Re-running the installer is idempotent.

Before you put anything you care about in a loot repo, read known issues — the ways loot can currently lose or strand work, written from our own testing, with a last-reviewed date on it.

All platforms

Prebuilt binaries, served from dl.millerbyte.com. Windows and Linux are on 0.4.24; macOS is on 0.4.14 — this release shipped no macOS build (see the version column below). Download and unpack manually if you'd rather not pipe a script.

Platform	Version	Download
macOS (Apple Silicon)	0.4.14	loot-cli-aarch64-apple-darwin.tar.xz (direct)
macOS (Intel)	0.4.14	loot-cli-x86_64-apple-darwin.tar.xz (direct)
Windows (x64, and ARM64 under emulation)	0.4.24	loot-cli-x86_64-pc-windows-msvc.zip (direct)
Linux (x64, gnu)	0.4.24	loot-cli-x86_64-unknown-linux-gnu.tar.xz (direct)
Linux (ARM64, gnu)	0.4.24	loot-cli-aarch64-unknown-linux-gnu.tar.xz (direct)

Verify your download

Every release publishes a unified sha256.sum beside the archives. Hash what you downloaded, compare it against that file. This is an integrity check, not a provenance one — the difference is spelled out below, and it is the whole of what loot offers.

Checksum

Hash the archive and compare it against the published sum.

# Windows (PowerShell)
Get-FileHash .\loot-cli-x86_64-pc-windows-msvc.zip -Algorithm SHA256

# Linux
shasum -a 256 loot-cli-x86_64-unknown-linux-gnu.tar.xz

# ...then confirm the hash is the line for that file in:
curl -sSfL https://dl.millerbyte.com/v0.4.24/sha256.sum

# macOS
shasum -a 256 loot-cli-aarch64-apple-darwin.tar.xz

# ...then confirm the hash is the line for that file in:
curl -sSfL https://dl.millerbyte.com/v0.4.14/sha256.sum

The hashes in sha256.sum are lowercase; Get-FileHash prints uppercase. Compare case-insensitively. Each archive also has its own .sha256 file alongside it, if you'd rather fetch one line than the whole set.

What the checksum proves — and what it does not

A matching hash proves the bytes on your disk are the bytes this release published, intact and unmodified in transit. That is worth checking and it is a real guarantee.

It does not prove who built them. The archive and sha256.sum ship from the same place, so anyone able to substitute one could substitute the other. A checksum is a statement about bytes, not about origin.

There is no provenance check to run, and that is a decision, not a gap. GitHub Artifact Attestations — the usual answer — are unavailable on user-owned private repositories, and loot builds in one. That is a settled choice, not a temporary state, so attestations are not pending: they are out, and SHA-256 is the integrity story on purpose. An earlier version of this page documented a gh attestation verify command. It could never have succeeded here, and it has been removed rather than left to fail.

Where the bytes actually come from. Both halves of the one-liner are served by infrastructure this project controls, and neither is GitHub. loot.millerbyte.com serves the install script: the release's own cargo-dist installer, re-served with its download list rewritten.

That list has three entries, tried in order. First loot.millerbyte.com/dl/…, which counts the download and immediately redirects to dl.millerbyte.com — it is how we know whether anyone installs loot at all, since nothing else in the chain can tell us. It records the release, the platform and the time; it does not record who you are. Then dl.millerbyte.com itself — Cloudflare R2, where release CI mirrors every asset, and where the bytes come from either way. Then the private GitHub Release, which only a credentialed fetch can use.

⚠ The order is also the fallback: a failed entry costs one request and the next is tried. If the counting hop is down you get the archive straight from dl.millerbyte.com and nothing about the install changes. Privacy describes what the count records.

The one-liner is protected by TLS and nothing else — neither installer carries an embedded checksum, by design, which is how uv and the other cargo-dist tools ship. TLS covers the transport; nothing in the automated path speaks to who built the bytes. For defense in depth, download manually from the table above and run the checksum.

Build from source

You cannot, and that is deliberate. loot's source repository is private permanently (ADR 0045) — the world reads loot through loot, not through a host's permission bit — so there is no cargo install route and no source archive to fetch. loot ships as the prebuilt, checksummed binaries above, and the hosted one-liner at the top of this page is the supported path.

If cargo install loot is what brought you here: the loot and loot-forge crates on crates.io are ours, and they are signposts back to this page rather than a route — both are lib-only, so they install nothing and cannot shadow a real install. ⚠ The crate published as loot-cli is a different project entirely: unrelated to loot, and unrelated to the loot-cli-* archives listed above.

What that costs you is real: you are trusting bytes you did not compile. The counterweight is on this page rather than in a promise — every archive is listed with its SHA-256 in the all-platforms table, so a manual download can be verified before it runs, and Evidence carries the run output behind each claim loot makes about itself.

Troubleshooting

loot not found after install — the installer prepends ~/.loot/bin to your PATH (via the user registry on Windows). Open a fresh shell so the change is picked up.
Confirm the version — loot --version prints the binary's self-reported version; a versioned release and the binary can't drift.
Manual install — grab the archive for your platform from the all-platforms table above, unpack it, and put the loot binary anywhere on your PATH. Those links go through loot.millerbyte.com/dl/…, which counts the download — the release, the platform and the time, not who you are — and sends you on to dl.millerbyte.com, which serves anonymously. The direct link beside each one skips the count and goes straight there. The GitHub releases page serves neither.