Package Registry Storage Bills Drive npm-Scale Caching Economics
Package registry costs scale with bytes stored and bytes served, not with the number of packages published. That distinction decides whether a registry bill stays flat or compounds annually. Consider a single popular package: its tarball might be 5 MB, and with 10 million weekly downloads, that is 50 TB of egress per week from one package alone. Multiply by thousands of similarly popular packages, and the bandwidth line item dwarfs compute and storage combined. This piece breaks down where the money goes at npm scale, how content addressing changes the math, and which caching layers pay for themselves within a quarter.
The Real Bill Behind npm
Registry storage grows faster than download traffic in most public registries. Every published version is retained indefinitely by default, and a single popular package can accumulate thousands of tarballs over a decade. Download counts rise linearly with adoption; storage rises with every minor patch, abandoned fork, and transitive dependency that nobody remembers installing.
Egress costs dwarf compute for tarball serving. Object storage is cheap per gigabyte at rest, but moving that gigabyte to a CI runner in another region is where the invoice grows. A registry that serves a few hundred terabytes a month can spend the majority of its infrastructure budget on bandwidth rather than disks or CPUs.
Metadata requests hit databases, not object stores. Resolving a dependency tree means querying version lists, dist-tags, and peer dependency ranges. Those lookups are small in bytes but expensive in query volume, and they resist the cheap horizontal scaling that object storage enjoys. A registry with a fast tarball path and a slow metadata path still feels broken to users.
Sponsorship and free-tier models hide per-package economics. A package with ten million weekly downloads may cost the registry operator thousands of dollars a month in egress while contributing nothing directly. The subsidy is absorbed by enterprise private registries and paid support contracts, which means public registry pricing is a cross-subsidy, not a cost-recovery exercise.
Content Addressing Changes the Math
Content-addressable storage deduplicates identical tarballs across versions. When two packages ship the same file contents, CAS stores one blob and two references. The savings are modest for unique code but substantial for vendored dependencies, generated artifacts, and the long tail of packages that republish unchanged files under new version numbers.
Immutable blobs simplify cache invalidation. A content hash never changes, so a CDN can cache a tarball indefinitely without revalidation logic. That property turns a hard distributed systems problem into a lookup table. It also means a corrupted or malicious tarball cannot be silently replaced under the same hash, which is a security property as much as a performance one.
Computing a SHA-512 digest on every publish and every fetch costs cycles, but the alternative is storing and serving duplicate bytes. At npm scale, the CPU is rounding error against the bandwidth saved. The tradeoff only flips for very small packages where hashing overhead approaches the payload size.
Yarn and npm both use content-addressable caches on the client side. Yarn's cache directory and npm's cacache store tarballs by content hash, so switching between projects that share dependencies avoids re-downloading. The same principle applies server-side, which is why registry operators lean on CAS for their own storage tiers.
Where the Margin Actually Lives
CDN contracts reward high cache-hit ratios. A provider that serves 95 percent of requests from edge nodes charges far less than one that forwards every request to origin. Registry operators optimize for hit ratio because it directly reduces origin egress, and origin egress is the line item that scales with success.
Cold storage for old versions cuts costs by an order of magnitude. Tarballs that have not been fetched in a year can move to archival tiers with higher retrieval latency and lower storage cost. The retrieval penalty is invisible for abandoned packages and painful for the occasional archaeology project that pins a 2016 version.
Metadata databases resist cheap horizontal scaling. Version lists, dependency graphs, and security advisories need consistent reads and fast joins. Sharding helps, but it introduces cross-shard queries that slow down exactly the resolution step users notice.
Free tiers are subsidized by enterprise private registries. Companies pay for access control, audit logs, and private package hosting, and those contracts fund the public infrastructure. The arrangement works until a small number of public packages consume a disproportionate share of egress, at which point operators introduce rate limits or download throttling.
Caching Layers That Pay for Themselves
Local proxy caches cut CI egress by half or more. Consider a typical Node.js monorepo with 1,200 dependencies. A cold install pulls roughly 250 MB of tarballs; a warm proxy cache serves the same tree from a local volume for under 20 MB of origin traffic, because only changed packages are fetched remotely. The tenth CI job that installs the same dependency tree fetches from the local network instead of the internet. The savings compound across every pipeline in the organization.
Lockfile-only installs reduce metadata round trips. When a lockfile pins exact versions and integrity hashes, the package manager can skip version resolution entirely and fetch tarballs directly. That eliminates the database queries that dominate metadata load and makes installs faster and cheaper at the same time.
Immutable version pinning improves CDN hit rates. A dependency pinned to an exact version with a content hash is cacheable forever. A range like ^1.2.0 forces revalidation and can resolve to a new tarball at any time. Teams that pin aggressively get better cache behavior without changing their registry provider.
Shared team caches need eviction policies. An unbounded proxy cache grows until the disk fills, and then builds fail in confusing ways. A simple LRU policy with a size cap, plus a periodic prune of packages not fetched in ninety days, keeps the cache useful without turning it into a liability. This mirrors the tradeoffs in build graph aging, where stale artifacts quietly accumulate cost.
Cost Modeling for Build Engineers
Track bytes served per install, not requests. A million metadata requests cost far less than a thousand tarball downloads of a large package. Per-install byte counts tell you which dependencies dominate your egress and which caching investments would actually move the needle.
Separate metadata latency from tarball bandwidth. They have different cost structures and different fixes. Metadata problems need database tuning or resolution caching; bandwidth problems need CDN configuration, compression, or a local proxy.
Model twelve-month storage growth from publish rates. If your organization publishes fifty versions a month at an average of two megabytes each, that is roughly 1.2 gigabytes a month, or about 14 gigabytes a year before deduplication.
Multiply by the number of internal packages and the retention policy becomes a budget decision rather than an afterthought.
Compare registry egress to a self-hosted mirror. For large organizations, a mirror in the same cloud region as the build fleet can cut egress costs substantially. The tradeoff is operational overhead: someone has to run the mirror, patch it, and handle the day it falls behind. A related piece on retry budgets across services makes a similar point about hidden operational costs that do not appear in the initial estimate.
What to Do Monday Morning
Audit your lockfile for redundant tarball fetches. Look for duplicate packages at different versions and check whether a resolution bump would collapse them into one. Each collapsed duplicate is a tarball your CI no longer downloads on every run.
Enable a local or CI-level registry proxy. Point your package manager at a caching proxy that persists between builds, and measure egress before and after. Most teams see a meaningful drop within the first week, and the proxy pays for its own storage in saved bandwidth. But be aware of the downsides: a cold cache after a proxy restart can make the first build painfully slow, and a misconfigured proxy can serve stale or poisoned tarballs if integrity checks are skipped. Running the proxy also adds operational burden—someone must monitor it, update it, and handle failures when it inevitably goes down.
Set a retention policy for unused private versions. Delete or archive versions that have not been downloaded in six months, and document the policy so nobody is surprised when an old build fails. The storage savings are real, and the retrieval path for archived versions should be tested once before you rely on it.
Measure install egress cost per developer per month. Divide your registry egress bill by the number of active developers and CI runs, and track that number over time. It turns an abstract infrastructure line item into a metric your team can actually influence.
Negotiate CDN pricing with cache-hit data. Bring hit ratios, origin egress volumes, and peak request rates to the table. Providers price on those numbers, and a registry with a documented 95 percent hit ratio has more leverage than one that cannot say what its origin sees.
