Archive, transfer or delete: retiring an open source repository

Archive when you want to stop but keep the code and history visible. Transfer when a trusted person will keep it alive. Delete rarely, because users and mirrors still depend on it. Whichever you pick, tell users what happens to security fixes, because that is their main question.

The three options

Archive. GitHub says archiving makes the repository read-only for everyone and signals that it is no longer actively maintained. Issues, pull requests, code, releases, tags and more become read-only. It can be unarchived later. Contributors can still fork or star the project, and archived repositories remain searchable.

Transfer. The project moves to a new owner with its issues and history. See what moves and what breaks. Pick this only when someone credible has agreed to take it on.

Delete. The repository and its public history disappear from that location. Anything built on it breaks, and copies elsewhere become the only record.

A simple decision guide

• A trusted successor exists and wants it: transfer.
• Nobody will take it, but the code is still useful to read or fork: archive.
• The code is harmful or legally problematic: delete, and say why where you can.
• Unsure: archive. It is reversible, and deletion is not.

Before you archive

GitHub recommends closing issues and pull requests and updating the README and description. Add to that list:

1. State the end of support. Say plainly that security fixes will not be provided, and name a date.
2. Point to alternatives. Link to a maintained fork or replacement if one exists.
3. Publish a final release or notice on the registry. Many users find out about status through their package manager. See yank, unpublish or deprecate.
4. Update SECURITY.md to say reports will not be handled, so reporters do not waste effort or go public unexpectedly.
5. Check automation and secrets. Remove publish tokens, deploy keys and webhooks you no longer need.

What users need to hear

A dependency that stops getting fixes becomes a liability over time. Teams that rely on it need time to plan a move. Give them notice, a reason, and options. For the user's view of the same event, see what to do when a dependency repo is archived.

A note on Actions and alerts

GitHub's archive page does not describe how Actions or Dependabot behave in an archived repository, so do not assume. Turn off workflows and automation you no longer want before archiving, and check the settings afterwards. Per the same page, code scanning alerts become read-only, and secret scanning can be enabled on archived repositories for customers who use GitHub Secret Protection.

Registry accounts outlive the repository

Archiving the repository does not stop anyone publishing under your registry account. If your tokens leak later, an attacker can still push a release to an abandoned package. Remove or rotate publish credentials, and keep two-factor authentication on the account.

If you depend on a project that is being archived, Safeguard's dependency scanning can show where it sits in your tree.

Quick check

Sources

• Archiving repositories (GitHub Docs)
• Transferring a repository (GitHub Docs)

Last reviewed: 19 October 2026.