Releases CLI

releases.sh · Backend monorepo → · Install · Usage · Authentication
The changelog & release-notes registry for developers and AI agents — a lean HTTP client for releases.sh. Search and browse release notes from GitHub, RSS/Atom/JSON feeds, and product changelog pages, with no local infrastructure.
This repo is the CLI only. The backend that powers api.releases.sh — the API worker, MCP server, web frontend, and ingest pipeline — is open source in its own repo: buildinternet/releases.
The CLI talks to the hosted registry at api.releases.sh. Search and browse work out of the box — no account or config. Sign in with releases login to follow orgs and products, get a personalized feed, and manage outbound webhooks; it mints a personal read-only API key (and earns you higher rate limits as those roll out). Write/admin access (releases admin …) is a separate, closed beta — open an issue for early access.
Install
brew install buildinternet/tap/releases
npm install -g @buildinternet/releases
curl -fsSL https://releases.sh/install | bash
Or run without installing: npx @buildinternet/releases@latest search react — always pin @latest, since bare npx @buildinternet/releases caches the first-fetched version forever. Signed, precompiled binaries for every platform are on the Releases page (with checksums) for air-gapped installs or version pinning.
Homebrew installs shell completions automatically. On every other path, enable them once with releases completion install (auto-detects $SHELL).
Usage
releases search "authentication"
releases search "slack integration" --since 90d
releases tail next-js
releases list --category ai
releases get vercel
releases org overview vercel
releases stats
releases submit https://acme.dev/changelog
releases feedback "great tool — here's an idea…"
Identifiers are interchangeable: every command accepts a slug, a typed ID (org_…, prod_…, src_…, rel_…), or an org/slug coordinate (e.g. vercel/next-js). IDs are stable across renames. search, tail/latest, and feed take --since / --until to bound releases by date — an ISO date (2026-01-01) or relative shorthand (90d, 4w, 6m, 2y).
Add --json to any reader command for machine-readable output — list commands emit a { items, pagination } envelope. Release readers return a slim shape by default (id, version, title, summary, excerpt, url, dates, plus any media with its r2Url); pass --full for the complete payload. tail/latest take --count (alias --limit, 1–100). Run releases <command> --help for per-command flags.
Following & personalized feed
Follow orgs and products to build a personalized feed. These act on your own account, so sign in first (releases login):
releases follow vercel
releases following
releases feed
releases unfollow vercel
Following an organization includes all of its products.
Outbound webhooks
Receive signed release.created POSTs in real time — for everything you follow or a single org:
releases webhook add --scope follows --url https://your.app/hook
releases webhook add --org vercel --url https://your.app/hook --description "prod"
releases webhook list
releases webhook test <id>
releases webhook verify --key … --signature … --timestamp … --body-file capture.json
Org-scoped: up to 10 (--org, optional --source, --product, --type feature|rollup). Follows-scoped: one webhook (--scope follows) that tracks your current follow graph; optional --type narrows delivery. Signing keys are shown once on add / rotate-secret. You can also manage webhooks in the browser at releases.sh/account/notifications. Operator/admin webhooks (releases admin webhook …) are a separate root-key surface.
Contribute to the registry
None of these need an account or API key:
releases submit https://acme.dev/changelog
releases feedback "tail -f reconnects slowly"
releases json validate releases.json
submit and feedback both prompt interactively when run with no argument, accept input on stdin, and take --dry-run --json to preview the payload without sending. feedback --type is bug / idea / other; submit --note carries extra context (product name, repo, feed quirks). Submissions feed the same review queue as the web submit form.
json validate is a read-only manifest check: it validates a releases.json v2 file against the published schema (pass a path or - for stdin) and adds --json for machine-readable output — no network, no submission.
MCP & Claude Code
Point any MCP-compatible agent at the hosted server:
npx mcp-remote https://mcp.releases.sh/mcp
This repo is also a Claude Code marketplace with the releases plugin — hosted MCP tools, a /releases lookup command, and auto-trigger skills:
/plugin marketplace add buildinternet/releases-cli
/plugin install releases@releases
Operator/maintainer skills (source onboarding, parsing, playbooks) live with the backend in the releases monorepo — its .claude/skills/ tree is picked up automatically in a checkout.
Or install just the skills into any agent (Cursor, Codex, Gemini CLI, Windsurf, …):
releases skills install
Authentication
Search and browse need no auth. Signing in powers the personal surfaces — follows, feed, and outbound webhooks — and mints a personal read-only key (it can't write to the catalog or run admin commands; it identifies you for /v1/me/* account routes). The easiest way in is your browser — nothing to copy or paste:
releases login
releases login --no-browser
This uses the OAuth 2.0 Device Authorization Grant (RFC 8628): approve a short code at releases.sh/device in a signed-in browser, and a read-only key is saved to ~/.releases/credentials (0600). Manage keys with releases keys list / create / revoke.
Already issued a token (e.g. a write/admin key during the closed beta)? Store it without the browser flow via releases auth login (interactive, --token <token>, or --token - for stdin); it's verified before being saved. releases auth status shows the current state (whoami is an alias). RELEASES_API_KEY in the environment overrides any stored credential — handy for CI.
Environment
Reader access requires nothing. Useful overrides:
RELEASES_API_KEY — Bearer token for write endpoints; overrides stored credentials.
RELEASES_API_URL — override the default https://api.releases.sh (e.g. staging).
RELEASES_TELEMETRY_DISABLED=1 — opt out of anonymous usage pings (DO_NOT_TRACK=1 also honored).
See .env.example for the full list.
Custom CA certificates (TLS-intercepting proxies)
The compiled binary ships with the standard Mozilla CA store. If your network re-terminates TLS with its own CA (corporate proxy, sandboxed agent environment), point the standard Node/OpenSSL variables at the proxy's CA certificate — the binary honors both:
NODE_EXTRA_CA_CERTS=/path/to/proxy-ca.pem releases search "bun"
SSL_CERT_FILE=/path/to/proxy-ca.pem releases search "bun"
No --ca-bundle flag is needed; certificate errors from the CLI include this hint.
Exit codes
0 | Success |
1 | Application error (network, API, unexpected state) |
2 | Usage / provider error (bad arguments or upstream rejection) |
130 | Cancellation (SIGINT) |
Contributing
Build, test, and release instructions live in CONTRIBUTING.md.
License
MIT