Playbook

GitHub: A Successor for Public Repos, and Nothing for Private Ones

Platform claims verified July 26, 2026

What this mechanism is

GitHub has a real, documented succession feature. In Settings > Account > Successor settings you name another GitHub user, and after your death that person can take over your repositories.

Read the limit carefully, because it is the whole story:

A successor can archive your public repositories, transfer them to their own account, and transfer them to an organization where they can create repositories.

A successor cannot log into your account, and cannot access your private repositories.

For most people that is exactly backwards from where the value is. Public repos are already public: worst case the code survives on forks, mirrors, and package registries. The private repos are the client work, the unreleased project, the notes, the infrastructure that runs something the family depends on. Those the successor cannot reach at all.

So GitHub gets you an orderly handover of the public half, and you have to solve the private half yourself.

Set it up now

Name a successor: Settings > Account > Successor settings, then add a GitHub user by username, full name, or email. Pick someone technical enough to know what to do with a repository, and tell them.
Inventory your private repositories and decide, for each, whether anyone would need it. Most people find two or three that genuinely matter and a long tail that does not.
For the ones that matter, pick a route the successor mechanism does not provide:
- Move them into an organization with a second owner. Organization ownership survives you independently of your personal account, and this is the cleanest answer for anything with ongoing value.
- Or mirror them somewhere the estate can reach: a clone on the machine at home, or an encrypted archive stored with your other exports.
- Or escrow credentials in Layer 2, understanding the caveat in Gotchas.
On the account card (Layer 1), record: your GitHub username, who the successor is, whether private repos exist and where the mirror or organization is, and any organizations where you are the sole owner.
Sole ownership of an organization is a bus factor. If an org has exactly one owner and that is you, add another owner today. Nothing in the successor mechanism fixes an orphaned organization.
Note anything downstream of the account: published packages (npm, PyPI, crates.io), GitHub Actions secrets, deploy keys, and anything using your account as an OAuth identity. These outlive you attached to an account nobody can sign into.
Escrow 2FA recovery codes in Layer 2. GitHub enforces 2FA, and the recovery codes are what stand between a mirror plan and a locked door.

What AmberKey stores

Layer 1 (metadata): username, named successor, whether private repos exist and where their mirror lives, organizations where you are sole owner, and any published packages that depend on the account.
Layer 2 (bearer secrets): 2FA recovery codes, a personal access token if you deliberately created one for this purpose, and credentials if you escrow them.
Do not store the assumption that the successor covers everything. Write the private-repo plan down explicitly, because the feature’s name invites the opposite conclusion.

What your survivors do

The named successor requests access through the GitHub Support portal. Two evidence routes exist and they differ in speed: a death certificate then a 7-day wait, or an obituary then a 21-day wait. GitHub may also ask for the requester’s photo ID and documentation showing they are authorized to act.
Once granted, transfer or archive the public repositories. Transferring into an organization is usually better than into a personal account, since it survives the successor too.
For private repositories, use the plan on the card, not GitHub. The successor route does not reach them. If a mirror exists, use it. If the repos live in an organization with another owner, that owner already has them.
Check for published packages. An unmaintained package with an unreachable maintainer is a supply-chain problem for everyone downstream, and registries have their own (slow) processes for it. Flag it early to any co-maintainers.
Rotate or revoke anything the account authenticates: deploy keys, Actions secrets, OAuth grants to third-party services. These are live credentials attached to a person who is gone.
Do not delete the account until the above is done. Deletion is immediate and takes the public repositories with it unless they were transferred first.

Required documents

Death certificate (7-day wait) or a link to an obituary (21-day wait), plus, where GitHub asks, the requester’s photo identification and documentation confirming authority to act for the deceased user’s account.

Expected timeline

Successor access: 7 days after a death certificate, 21 days after an obituary, plus GitHub’s own review. Private repositories: immediate if a mirror or organization exists, otherwise not at all.

Gotchas

“Successor” sounds broader than it is. Public repositories only, no login, no private repositories. Everyone who reads the feature name assumes more.
Sole ownership of an organization strands it. Add a second owner while you can; there is no successor path for an org.
Escrowed credentials conflict with GitHub’s own process. Signing in as a deceased user violates the terms and can get the account suspended mid-estate. Escrow them for the mirror-and-rotate case if you like, but the successor route is the sanctioned one, and a mirror is the better answer for private work.
Published packages outlive the account. npm, PyPI, and crates.io each have separate maintainer-succession processes, all slower than GitHub’s. If you publish anything with users, add a co-maintainer now.
2FA is mandatory on GitHub. Without recovery codes there is no credential path at all, even where one would otherwise be appropriate.
Forks are not a backup. They preserve code that was already public; they do not preserve issues, wikis, releases, or anything private.