If a dependency vanishes from the registry, a lockfile will tell you what you needed but cannot supply it. You can still build if you hold a copy: a mirror, a populated cache or vendored source. Plan this before you need it, and verify copies by checksum.
What a lockfile does and does not do
A lockfile records exact versions and usually integrity hashes. That makes a rebuild predictable when the registry cooperates. It does not store the packages. The reproducible-builds documentation says inputs from the network are volatile, even when they do not seem to be, and recommends two things: ensure integrity using cryptographic checksums, and keep backups, ideally with a fallback location.
That is the whole problem in two sentences. The checksum tells you whether what you got is what you expected. The backup is what lets you get it at all.
Ways a dependency can disappear
- A maintainer removes a release or the whole package.
- A registry has an outage during your release window.
- A package is taken down after a security problem.
- A project moves hosting and the old URL stops working.
- A tool you download in a build script is no longer hosted at that address.
Each case blocks a build that was fine yesterday.
Your options
| Option | How it works | Cost |
|---|---|---|
| Internal mirror or proxy | Your registry proxy keeps copies of what you fetch | Run and secure one more service |
| Pre-populated cache | CI cache or artifact store holds downloaded packages | Cache expiry and size limits |
| Vendored source | Copy lives in your repository | Review and update burden |
| Archive on release | Save the dependency set with every release build | Storage per release |
Each option should be paired with verification. Whichever store you use, compare the hashes of what you hold to the hashes in the lockfile. The FreeBSD ports system, which the project cites as a good example, lists source files with cryptographic checksums and keeps copies on a mirror network so a build can fall back when the original site is unreachable.
Steps for a small team
- Find out what you fetch. Run a build offline from a clean state and list every failure. The offline build test covers this.
- Pick one store. For most small teams, a pull-through proxy or an archive saved at release time is the least work.
- Verify. Check hashes on the way in and on the way out.
- Test a restore. Once a quarter, rebuild an old release using just your store with the registry blocked.
- Decide what to do on removal. If a package you use is pulled for a security reason, you want to know why, not just keep building quietly. Pair the archive with vulnerability monitoring so you hear about advisories.
The security trade
Keeping a copy is good for availability and reproducibility. It is not a reason to stop updating. A copy of a package with a known flaw is still a package with a known flaw, and archived dependencies need the same scanning as live ones.
Where Safeguard fits
Safeguard's SBOM and dependency scanning, plus continuous monitoring of what you ship, covers the flaw side of archived dependencies. Free scan: gold.safeguard.sh/scan.
Quick check
Does a lockfile with hashes protect me from a removed package?
It protects integrity, not availability. You still need a copy.
Is an internal mirror required for a small team?
No. A saved dependency archive per release can be enough, if you test restoring from it.
Sources
Last reviewed: 19 October 2026.
