It depends on why the package was removed. If the author withdrew it for convenience, keeping your copy protects your builds. If it was removed for malware or a serious security problem, purge it. Check the reason, decide deliberately, and record the decision.
Why this question matters
A mirror stores copies. That is useful when an upstream deletion would otherwise break your builds. The left-pad episode in 2016 is the classic example of unpublishing causing widespread build failures, discussed in our post on what unpublish taught npm.
The same property is dangerous when the removed package was malicious. A mirror that keeps serving it keeps handing it to developers, long after the public registry stopped.
Decision table
| Reason for removal | Typical action in your mirror |
|---|---|
| Author unpublished voluntarily, no security issue | Keep the approved version, note the risk of no more upstream updates |
| Package abandoned or declared unmaintained | Keep for now, plan a replacement |
| Licence dispute or takedown notice | Hold and ask the licence reviewer before serving it further |
| Malicious code found | Purge from the mirror, search builds and artifacts for use, treat as an incident |
| Security flaw with no fix | Block the version, keep an exception path if needed |
Licence and takedown cases involve legal judgement, so route them to your counsel.
Steps when you learn a package was removed
- Confirm the removal and read the registry's stated reason, if any.
- Search your inventory for use of the package and versions.
- Classify the reason using the table above.
- Apply the action to the mirror, and record who decided and when.
- If you kept it, open a task to find a replacement or to take on maintenance.
- If you purged it, check build caches, container images and developer machines.
Our runbook on pulling a malicious version out of your mirror covers the purge steps in detail.
Caution about retained copies
A retained copy is frozen in time. It will not get security fixes. Treat it as a package with a clock on it: add it to the exception or watch list, set a review date, and plan removal.
Also note that a mirror serving a deleted package can hide the removal from developers. Make sure the platform team learns of upstream removals, for example through registry notices or advisory feeds, rather than finding out when a build fails.
What to record
- The package, version and date you learned of the removal.
- The reason and the source you used to confirm it.
- The decision, owner and date.
- The search results showing where the package was used.
- The follow-up tasks and their due dates.
Quick check
Does a mirror protect me from an upstream malicious release?
Not by itself. A mirror can serve a bad version just as readily as a good one unless you add checks or holds before promotion.
Can I keep a deleted package forever?
You can, but without upstream fixes it becomes a growing risk. Put a review date on it and plan a replacement.
Safeguard dependency scanning and asset discovery can show where a removed package is still in use. A free scan is available at gold.safeguard.sh/scan.
Last reviewed: 19 October 2026.
