Package Registry Overview
Pure provides an npm-compatible package registry at:
https://registry.pure.devThe registry stores Pure-compiled packages as native .node add-ons and proxies any package not found locally to npmjs.org. From a client perspective it behaves exactly like the official npm registry — use it as a drop-in via .npmrc.
What it stores
Section titled “What it stores”| Category | Description |
|---|---|
| Pure-compiled packages | A curated set of popular npm packages that Pure has tested and certified as byte-identical to their real npm behavior, compiled to native .node modules. Published automatically by Pure — see How packages get published. |
| Proxied npm packages | Everything else. Metadata is fetched from npmjs.org on demand and cached; tarball bytes are never stored or re-served by us — see Proxy behaviour below. |
The registry does not store source code, and it does not store or re-serve tarball bytes for packages it doesn’t publish itself — only compiled artifacts we actually publish.
When to use it
Section titled “When to use it”npm install from a Pure project: set registry=https://registry.pure.dev in your .npmrc so certified packages resolve to the faster compiled version automatically, and everything else falls through to npmjs. See Configure npm.
Proxy behaviour
Section titled “Proxy behaviour”When the registry receives a request for a package it does not have locally, it:
- Fetches the packument (package metadata) from npmjs.org and caches it with a configurable TTL. If the client requests the abbreviated (“install-only”) metadata format npm CLI normally asks for, the response is trimmed to just the install-relevant fields (no readme, maintainers, or publisher history) — substantially smaller than the full document. Responses are gzip-compressed.
- On tarball requests for a version not published to Pure, the registry does a HEAD-only existence check against npmjs.org (headers only, no body) and then redirects the client (302) straight to npmjs.org — it never downloads or re-serves the tarball bytes itself. Real npm/Bun/pnpm clients follow the redirect and pull the bytes directly from npmjs.org.
If npmjs.org is unreachable when checking a tarball’s existence, or a metadata fetch fails, the registry falls back to the most recently cached metadata (packuments only — tarballs are never cached) and returns a retryable 503 for tarballs rather than a false 404. A package that has never been cached and cannot be reached returns 404.
ETags are used for packument conditional re-validation so upstream metadata bandwidth is minimized. Tarball bytes for proxied (non-Pure) packages never cross Pure’s infrastructure at all.