How to Archive a GitHub Repository (and When You Should Not)

Eventually every team has a repository that nobody has touched since the last reorg but nobody wants to delete either. Archiving is GitHub's answer to that situation: it makes a repository read-only and marks it as retired, without removing anything.

This guide walks through the actual steps, explains precisely what archiving does and does not change, and covers the cases where transfer or deletion is the better move.

What archiving does

An archived repository becomes read-only. Concretely:

• Issues, pull requests and discussions become read-only. Nobody can open new ones; existing ones cannot be commented on.
• Releases and packages stay available. Existing tags, releases and published packages keep working, which matters if something still installs from them.
• Everyone gets read access by default. Archiving makes the repository public for reading within your organisation — a quiet benefit, because builds and audits can still read it.
• It becomes easy to find as retired. GitHub shows an archived banner and excludes it from most default listings, which is the point: the active list gets shorter.
• You can still clone it. Read-only means no pushes, not no reads.
• Nothing is deleted. Code, history, branches, tags and releases all remain.

How to archive a repository

1. Open the repository on GitHub and sign in with admin rights on it.
2. Go to Settings in the repository's top navigation.
3. Scroll to the bottom to the Danger Zone.
4. Next to Archive this repository, click Archive this repository.
5. Type the repository name to confirm, then confirm again.

For many repositories at once, the gh command line is faster:

gh repo archive OWNER/REPO --yes

To find candidates first, list repositories and sort by last push:

gh repo list OWNER --limit 200 --json name,pushedAt,isArchived \
  --jq '.[] | select(.isArchived==false) | [.pushedAt, .name] | @tsv' | sort

Before you click archive

Five checks, two minutes, no surprises later:

1. Is anything still building from it? Search your CI configs for the repository name. An archived repo still serves clones, so this usually still works — but a pipeline that pushes a tag or commits a version bump will now fail.
2. Do any packages depend on its releases? Existing releases stay available, but you cannot publish a new one.
3. Are there open issues or pull requests worth keeping? Move anything still relevant to the successor repository before archiving, because you cannot comment afterwards.
4. Does it hold secrets or credentials? Archiving is not deletion. If the repo contains live keys, rotate them and see the deletion section below.
5. Does anyone still need to push to it? If yes, it is not dead yet.

How to unarchive

Archiving is reversible: the same Danger Zone has an Unarchive this repository button, and gh repo unarchive OWNER/REPO --yes does it from the terminal. A common pattern is to archive, wait a month, and see whether anyone shouts — if nobody does, you have learned something valuable.

What archiving is not

It is not a backup

Archiving changes permissions, not durability. If the account is deleted, the organisation is removed, or the repository is transferred, the archive goes with it. If your goal is "we must never lose this code", you need a copy outside GitHub — a mirror clone or a bundle file on your own storage. That is a separate task with its own guide: how to save a GitHub repository locally.

It is not a way to save money on most plans

Archived repositories still count towards storage in most cases. A large archived repo with heavy history still occupies space. Deleting genuinely dead repos is the only reliable way to reclaim storage.

It is not the same as a fork

A fork is a copy that can move independently. Archiving keeps one canonical repo and freezes it. If you forked something to abandon it, archive your fork and leave the upstream alone.

Archive, transfer, or delete?

Goal	Best action	Why
Code is finished, keep a readable record	Archive	Read-only, still cloneable, still searchable
Code has a new home	Transfer to the new owner	Redirects preserve links and clones; history is kept
Duplicate, spike, or secret leak	Delete	Archiving keeps content and access; deletion actually removes it
Must survive a lost account	Archive and mirror externally	Archiving does not copy anything off GitHub
Migrating between hosts	Transfer, then mirror to the new host	Transfer keeps issues and redirects; the mirror is the durable copy

Deleting after archiving, safely

If a repository turns out to be genuinely dead, deleting it is the honest move — but do it in the right order:

1. Take an external copy first (mirror clone or bundle) and store it wherever your other backups live.
2. Note in your inventory that the repo was deleted, and where the copy is.
3. Delete: Settings → Danger Zone → Delete this repository, or gh repo delete OWNER/REPO --yes. A deleted repository can sometimes be restored within a short window, but do not plan on it.

One caution: deletion does not erase history from forks. If credentials leaked, rotate them; assume the code is public forever.

Archiving well: the habits that matter

• Write a retirement note before archiving. Add a line to the README — "Retired in 2026, replaced by billing-ledger-api" — and then archive. Future readers land on a read-only page; the note is the only thing that explains it.
• Point forward, not backward. The note should name the successor, not the history. That is the one click a future reader will always want.
• Archive in batches, quarterly. Ten minutes per quarter, driven by last-commit date, beats a heroic annual cleanup. Batch work with a gh loop and a candidates list.
• Keep an inventory. A single sheet listing active, archived and deleted repositories, with the successor for each retired one, answers "what happened to X?" without archaeology.

The bottom line

Archiving is a permissions change that says "this is finished". It is cheap, reversible, and appropriate for the majority of repositories with no commits in the last year. It is not deletion, it is not a backup, and it does not save storage. Decide which of those three problems you actually have — then archive, transfer, or delete accordingly.

Doing this across a whole organisation is mostly bookkeeping: classify every repo, write the forward pointer, archive in batches, and keep a list. If you would rather have that handed to you finished, repos.to runs the inventory and the archiving pass for your team.