To get a DOI for a GitHub release, log in to Zenodo with GitHub, switch on your public repository on the Zenodo GitHub page, then create a release. Zenodo archives the repository and issues a new DOI each time you publish a release. Include a license first.
What the DOI gives you
A DOI is a persistent identifier. It lets a paper point at an exact archived snapshot of your code, even if the repository is later renamed, moved or deleted. GitHub's documentation describes Zenodo as a data archiving tool that can archive a repository and issue a DOI for the archive.
Two limits are worth knowing. Zenodo can only access public repositories. For a repository owned by an organization, an organization owner may need to approve access for the Zenodo application.
Steps
- Add a license file to the repository so readers know how they can reuse your work.
- Log in to Zenodo and choose to log in with GitHub.
- Review the requested access permissions and authorize Zenodo.
- Open the Zenodo GitHub page and toggle the repository to On.
- On GitHub, create a new release from a tag.
- Wait for Zenodo to archive it, then copy the new DOI into your README and your CITATION.cff file.
Check before you tag
An archive is a frozen copy. Whatever is in the tag is what gets preserved, including mistakes. A short pre-release pass avoids permanent embarrassment.
- Search the tree for keys, tokens and passwords. A secret in an archived release cannot be recalled by deleting it from GitHub later.
- Remove large raw data you do not have the right to redistribute.
- Confirm the lockfile or environment file is committed, so the archive can be run later.
- Run a dependency scan so the release does not ship a known vulnerable library without you knowing.
A fixed bug means a new release
Because each release gets its own DOI, a security fix is a new version, not an edit. Say so in your release notes, and update the version and DOI in your citation file. Readers who cited the older DOI can then see that a newer one exists.
| Situation | What to do |
|---|---|
| Typo in README only | Normal commit, no new release needed |
| Bug that changes results | New release, new DOI, note in changelog |
| Vulnerable dependency | New release with updated lockfile |
| Leaked secret | Rotate the secret first, then release |
Try it yourself
Click through it at your own pace, or open it full screen. Look at how findings are prioritized, then imagine running that view just before you cut a release.
Quick check
Can I archive a private repository with Zenodo?
Per GitHub's documentation, Zenodo can only access public repositories, so make the repository public first.
Does every release get a new DOI?
Yes. GitHub's guide states that Zenodo issues a new DOI each time you create a new GitHub release.
Safeguard offers dependency scanning and a free scan you can run on a public repository before you tag a release.
Sources
Last reviewed: 19 October 2026.
