Built for the
ways you ship.

01 / USE CASE

Sell private libraries

You built a component library, a toolkit or an SDK worth paying for. Publish it once, grant each recipient the packages they need, and keep the commercial relationship yourself.

• ↗Recipients tracked under your own references, with suspend and resume
• ↗Package-scoped download keys with expiry and revocation
• ↗A self-service portal where recipients manage their own keys
• ↗You invoice; the platform never touches your sales

02 / USE CASE

Distribute a vendor SDK

Ship your product's client libraries to integrators without making them public. Each integrator gets credentials that see exactly the packages you grant them.

• ↗A separate download key for each integrator
• ↗Your own registry domain, so docs point at npm.you.com
• ↗Per-version and per-recipient download charts, and a CSV of who downloaded what

03 / USE CASE

Run your organization's private registry

Keep internal packages off the public registry and give every team and pipeline scoped credentials with the audit trail to match.

• ↗Publisher tokens narrowed by scope or package for CI
• ↗Roles, SSO and SCIM for the whole organization
• ↗Public npm dependencies cached on Growth and up, without a path for dependency confusion
• ↗Immutable versions, an audit log, and a transfer ledger of every byte

04 / USE CASE

Ship Python packages and files

The same organization can publish an npm SDK, a Python library and the binaries that go with them. Recipients get a download key for the registry they need.

• ↗pip, uv and poetry install from a private index; twine publishes
• ↗curl or wget for files, or an upload from the dashboard
• ↗The same recipients, keys and revocation you already use for npm