1. authenticate
Create a CLI token in the dashboard, then save it on your machine:
The token is stored under ~/.config/rune/token and sent as Authorization: Bearer rune_pat_*.
runebook
Every Rune ever published, content-addressed and capability-declared. Pick one, read the manifest, decide whether to install it.
runebook · publish
Runes are published from the CLI. The website verifies the manifest, deduplicates blobs against existing storage, and serves them. You authenticate with a personal access token from your dashboard.
Create a CLI token in the dashboard, then save it on your machine:
The token is stored under ~/.config/rune/token and sent as Authorization: Bearer rune_pat_*.
From your Rune directory:
The CLI resolves your file list, runs the esbuild publish preset, computes per-file sha256 hashes, and builds the canonical manifest. Identical content always produces the same manifest hash.
The CLI sends the manifest to the registry, receives pre-signed R2 PUT URLs for any blobs not already in storage, and uploads them directly to R2. Blobs are content-addressed: two Runes that ship the same file dedupe to one storage object.
Once every blob is in R2, the CLI calls finalize. The registry verifies presence, atomically registers the version, and returns the canonical install string. A half-uploaded publish is never visible.
Every host privilege your Rune asks for goes in the manifest's capabilities array. These appear on the detail page before the install command, weight-graded by trust cost. Capabilities are part of the manifest hash, so they are part of the version's identity: adding a capability requires a new version.
If you ship a broken version, you can soft-delete it:
Yanked versions remain installable for operators who pinned them, but disappear from the default resolver and show a warning banner on the detail page.
rune auth loginrune publishrune yank @<scope>/<name>@<version> --reason "broken on 1.21.4"