The npm registry protocol is a handful of HTTP endpoints. So Deel built its own.

The problem: 200+ repositories, one attack away

Deel has more than 200 repositories. Now imagine a new npm supply chain attack lands — a popular package gets hijacked and a malicious version is published. What happens next?

Someone has to answer a deceptively simple question: are any of our repositories using the compromised versions?

In practice, that question is brutal:

• You'd have to scan lockfiles across every repository — and support the lockfile formats of npm, pnpm, and yarn, across multiple versions of each.

• Lockfiles on the default branch aren't the whole story. Some developers have the malicious version sitting on a side branch, waiting to be merged. A scan of master tells you nothing about what installs on dev machines tomorrow.

• Even a perfect scan is reactive. By the time you're scanning, the package may have already run a postinstall script on someone's laptop.

Scanning lockfiles is fighting the problem at the wrong layer. Every install goes through a registry — so that's where the control belongs.

The idea: just build our own registry

"Let's build our own npm registry" sounds like a huge undertaking. On closer inspection, it's surprisingly small. The npm registry protocol is just HTTP, and to be compatible with any package manager — npm, pnpm, yarn — you only need to implement a handful of endpoints: package metadata, tarball download, publish, and a bit of auth. Every client speaks the same protocol, so one registry unifies them all.

So we built one: a caching registry proxy, deployed behind our VPN.

How it works

One choke point for all package traffic. Developers and CI point their package manager at the internal registry. Because it sits behind the VPN and implements the standard protocol, it works identically for npm, pnpm, and yarn — no per-tool tooling, no lockfile archaeology.

Configurable upstream mirrors. On a cache miss the registry walks an ordered list of upstream mirrors — the public npm registry, AWS CodeArtifact (with tokens fetched and refreshed automatically via the AWS SDK), or anything else with a URL and a token. A mirror that misses or errors falls through to the next.

Packages are cached in our own S3. Every tarball that comes through is stored in an S3 bucket we control — and that bucket is scanned. We keep our own copy of everything our builds depend on, which also insulates us from upstream outages and unpublished packages.
Pluggable security scanning. Because we own the registry, we can plug in any security intelligence we want — in our case, Aikido intel. The scan runs before a package ever reaches a developer's machine, not after it's already in a hundred lockfiles.

Unified policies across package managers. pnpm supports minimumReleaseAge — refusing versions published too recently, which blocks the window when most hijacked releases do their damage. old npm doesn't support it. With our own registry, that doesn't matter: we enforce the restriction server-side, and every client gets it for free.

Per-project visibility. Every route is namespaced by project, and the registry tracks which project uses which package versions, refreshed on every install and publish. When the next supply chain incident hits, "are we affected, and where?" is a database query — not a company-wide lockfile grep.

The payoff

What started as a defensive reaction to supply chain attacks turned into a better architecture overall:

• Prevention instead of detection. Malicious versions are blocked at the registry, before install.

• One policy, every tool. Release-age rules, blocklists, and scanning apply uniformly regardless of package manager.

• Instant blast-radius answers. Usage tracking replaces fleet-wide lockfile scans.

• Resilience. Our S3 cache means upstream incidents don't break our builds.

The lesson: the npm registry protocol is small enough that owning your registry is not a moonshot — it's a few endpoints. And once you own that choke point, an entire class of supply chain problems becomes tractable.