Publish to package registries + use download stats as primary adoption metric
Context
GitHub clone/view counts are noisy (CI inflation, our own activity) and can't be filtered by actor. We need a cleaner signal for "are real external users adopting byok-relay?"
Publishing byok-relay to package registries solves both problems at once: it makes installation easier (no git clone required) and gives us download counts that are far more meaningful than GitHub traffic numbers.
Registries to consider
npm (highest priority)
byok-relay is a Node.js server — publishing to npm as a CLI tool is natural and low-effort.
- Install: or one-shot
- No git clone, no manual env setup — just
- npm weekly download counts are public, real, and not inflated by CI
- Package name appears to be unclaimed (verify before publishing)
Bun
Same package, automatically available if published to npm. Bun resolves from the npm registry. No extra work.
pip / uv (lower priority, separate effort)
byok-relay is not a Python project, so a pip package would need to be either:
- A thin Python client SDK () for apps that want to interact with a running relay from Python
- A wrapper that shells out to the Node.js process (fragile, not recommended)
Worth doing once there is demand from Python users, but not before the Node.js distribution is clean.
How this improves metrics
Once published to npm:
- gives weekly/monthly download counts
- Downloads are real user installs — no CI noise, no our-own-activity
- Can track over time as the primary adoption signal
- Complements (and eventually replaces) GitHub clone tracking
Suggested CLI interface for npm package
Related
- Current tracking: GitHub clone uniques (noisy, CI-polluted)
- Future primary metric: hosted relay request volume (once relay is live)
- This issue bridges the gap between the two
Publish to package registries + use download stats as primary adoption metric
Context
GitHub clone/view counts are noisy (CI inflation, our own activity) and can't be filtered by actor. We need a cleaner signal for "are real external users adopting byok-relay?"
Publishing byok-relay to package registries solves both problems at once: it makes installation easier (no git clone required) and gives us download counts that are far more meaningful than GitHub traffic numbers.
Registries to consider
npm (highest priority)
byok-relay is a Node.js server — publishing to npm as a CLI tool is natural and low-effort.
Bun
Same package, automatically available if published to npm. Bun resolves from the npm registry. No extra work.
pip / uv (lower priority, separate effort)
byok-relay is not a Python project, so a pip package would need to be either:
Worth doing once there is demand from Python users, but not before the Node.js distribution is clean.
How this improves metrics
Once published to npm:
Suggested CLI interface for npm package
Related