An archived GitHub repository is read only and signals that it is no longer actively maintained. Issues, pull requests, code and releases cannot change, so no fixes will land there. Treat it as a planned exit: assess exposure, pick an alternative or a fork, and set a date.
What archiving does
According to GitHub, archiving makes a repository read only for everyone and indicates it is no longer actively maintained. Its issues, pull requests, code, labels, milestones, projects, wiki, releases, commits, tags, branches, comments and permissions cannot be changed. You cannot add or remove collaborators. People with access can only fork or star it.
It can be undone. A maintainer can unarchive from settings. So an archived repo is not always final, but you should not plan around a reversal.
What it means for your risk
Nothing changes in your build the day a repo is archived. Your pinned version still installs. The change is in the future: a newly discovered flaw will have no upstream fix. The longer you wait, the more risk accumulates.
Also check where the package is distributed. Archiving a repository does not by itself remove the package from its registry, so you may not see any warning in your build.
A decision path
- Confirm. Read the archive notice and the README. Some maintainers point to a successor project.
- Find the exposure. Which of your services use it, and is it a direct or transitive dependency? Is it on a path that handles untrusted input?
- Check for a successor. A maintained fork or replacement may already exist. Look at its recent activity, contributors and release history before you adopt it.
- Choose. Replace it, move to a trustworthy fork, or take it in house if the code is small and you can maintain it.
- Schedule. Put a date on the ticket. Without one, the item stays forever.
When to fork
Forking makes sense when the code is small, stable and you have people who understand it. It is a poor choice for a large, fast moving library, because you inherit all future work. See forking strategy for enterprise open source for the trade offs.
Living with it for a while
If you cannot move quickly, reduce exposure. Isolate the component, restrict what it can reach, and add a monitor for new advisories that name it. Record the decision and the review date so it does not become an unowned risk.
Look for the pattern across your estate
One archived dependency is a ticket. Ten is a pattern, and a sign that your intake process does not check maintenance. Add that check to adoption reviews. For more, see abandoned open source project risks and the long tail of abandoned projects.
Safeguard's SBOM and dependency scanning show where a component is used, reachability analysis helps judge whether a flaw is on a live path, and you can try a free scan.
Quick check
Does archiving delete the package?
Archiving makes the repository read only. It is not the same as removing a published package, so check the registry separately.
Can archiving be reversed?
Yes, a maintainer can unarchive the repository from settings.
Sources
Last reviewed: 19 October 2026.
