Often yes, but it depends on one setting. npm treats the public registry host in a lockfile as a stand-in for whichever registry you have configured. The replace-registry-host setting controls that behavior, and its default only rewrites the public host. Check it, then prove your builds really fetched from the mirror.
What the lockfile records
Each entry in package-lock.json has a resolved field, which records where npm got the package, and an integrity field, which is a checksum of the downloaded artifact. The lockfile docs describe the public registry host as a magic value meaning the currently configured registry. That is why a lockfile written by a developer on the public registry still works for a teammate whose npm points at the mirror.
The integrity value is what keeps this safe. Whatever host serves the file, npm compares the content with the recorded checksum.
The replace-registry-host setting
The config docs list four kinds of value for this setting: npmjs, never, always, or a string. The default is npmjs. The docs describe it as the behavior for replacing the registry host in a lockfile with the configured registry.
| Value | Effect on lockfile URLs |
|---|---|
| npmjs (default) | Public registry host is replaced by your configured registry |
| never | Lockfile URLs are used as written |
| always | The host is replaced every time |
The docs do not walk through every edge case, so treat the table as a summary and test the behavior with your npm version.
Why a small team should care
If one developer commits a lockfile whose resolved URLs name a different host, such as a personal feed or an old mirror, the default setting will not rewrite them. Builds then go to that host. Setting the value to always makes your configured registry win, which is usually what a team with one mirror wants. Setting never is right if you deliberately pin some packages to specific hosts.
Pick one policy and write it in the repository's npm config file so every machine and CI job agrees.
Prove the build used the mirror
Do not assume. A short check:
- Run a clean install in CI with a fresh cache.
- Look at your mirror's access log for the tarball requests.
- Confirm the count of tarball fetches roughly matches the number of packages in the lockfile.
- Scan the lockfile for resolved hosts that are not your mirror or the public default.
grep -o '"resolved": "[^"]*"' package-lock.json | sed 's|"resolved": "https://\([^/]*\)/.*|\1|' | sort | uniq -c
The output is a count per host. More than two hosts, or any host you do not recognize, deserves a look before the next release.
Where Safeguard fits
Safeguard's SBOM and dependency scanning lists every package in a project with its version, which gives you an inventory to compare with what your mirror served. A free scan is at gold.safeguard.sh/scan.
Try it yourself
Click through it at your own pace, or open it full screen.
Look at how the inventory lists each package and version, then compare that list with your mirror's access log.
Quick check
Does integrity checking still apply when the host is replaced?
Yes. The integrity field records the expected checksum of the artifact, so content from the mirror must match it.
Should the lockfile contain my mirror's URL?
Usually not. A lockfile with the public host plus a configured registry is easier to share and review.
Sources
Last reviewed: 19 October 2026.
