Archive your code with a DOI

Code hosting platforms are excellent places to build software. They are not designed to preserve a specific version forever. Repositories get renamed, transferred, made private or deleted. Branches move. Even when the repository survives, the code a reader finds next year may not be the code that produced your figures.

An archive solves this. It stores a frozen copy, assigns it a persistent identifier and commits to keeping it available. Your paper cites the identifier. The repository keeps evolving. Both are useful, and they do not compete.

What is a DOI and why use one for code?

A DOI, or Digital Object Identifier, is a persistent link that resolves to a landing page for a research output. Papers have them. Datasets have them. Software can too.

A DOI does three things for your code:

• It persists. If the storage location changes, the DOI is updated to point to the new location.
• It identifies a version. Each archived release gets its own DOI, so a citation points to exact code.
• It is citable. Reference managers, indexing services and many citation tracking systems understand DOIs.

The FORCE11 Software Citation Principles make the case that software should be cited like any other research output, with persistent identifiers and version specificity. The FAIR principles for research software (FAIR4RS) build on the same idea.

How do you get a DOI from GitHub via Zenodo?

Zenodo, a general purpose research repository operated by CERN, has an integration with GitHub that archives a repository each time you publish a release. The steps:

1. Log in to Zenodo with your GitHub account.
2. In Zenodo's GitHub settings, switch on archiving for the repository you want.
3. Prepare the repository: a README, a license and citation metadata (see below).
4. Create a release on GitHub with a version tag, for example v1.0.0.
5. Zenodo picks up the release, stores a snapshot and mints a DOI.

Check the Zenodo record afterwards. Titles, authors and descriptions are pulled from your metadata, and it is worth fixing them before you cite the DOI in a paper.

Which DOI should go in your paper?

Zenodo gives you two kinds of DOI:

• A version DOI for each release. It always resolves to that exact snapshot.
• A concept DOI that represents all versions and resolves to the latest one.

For reproducibility, cite the version DOI that matches the code used in your analysis. Use the concept DOI when you want to refer to the software in general, for example on a project website or in a README badge.

If you fix a bug after publication, make a new release. The old DOI stays valid, readers can see that a newer version exists, and your paper keeps pointing to what you actually ran.

What does CITATION.cff do?

Citation File Format is a small, human and machine readable file that tells people how to cite your software. Put a file named CITATION.cff in the root of the repository.

cff-version: 1.2.0
message: "If you use this software, please cite it as below."
title: "example-analysis"
version: 1.2.0
doi: 10.5281/zenodo.XXXXXXX
date-released: 2026-09-01
license: MIT
authors:
  - family-names: "Doe"
    given-names: "Alex"
    orcid: "https://orcid.org/0000-0000-0000-0000"
repository-code: "https://github.com/example-lab/example-analysis"

GitHub reads this file and shows a "Cite this repository" option. Zenodo can also use it as metadata for the archived record. If you want a related paper cited instead of, or as well as, the software, CFF supports a preferred-citation section.

Keep the version and date in sync with each release. A stale CITATION.cff is better than none, but not by much.

Where does Software Heritage fit?

Software Heritage is a non-profit initiative that aims to archive all publicly available source code. It crawls major hosting platforms and keeps the full development history, not just releases.

It uses intrinsic identifiers called SWHIDs. A SWHID is computed from the content itself, so it identifies an exact file, directory, commit or snapshot and cannot silently drift. Some journals and repositories accept SWHIDs alongside or instead of DOIs.

You can request an immediate archive of your repository through the "Save code now" feature on the Software Heritage archive. Doing this alongside Zenodo gives you two independent copies with two kinds of identifier at no cost.

What about Figshare and OSF?

Figshare and OSF also issue DOIs and accept code. They are good choices if your institution already uses them or if you want code, data and materials together in one project. Figshare also offers a GitHub integration. The principle is the same everywhere: archive a fixed version, get a persistent identifier, cite that.

What is a sensible release routine?

• At submission: tag a release, archive it, put the version DOI in the code availability statement.
• After revisions: if the code changed, make a new release and update the DOI in the manuscript.
• At publication: confirm the paper cites the final version and that the Zenodo record links back to the paper.
• Afterwards: keep developing in the repository. Make new releases when meaningful changes land.

Use semantic versioning if you can: increase the first number for breaking changes, the second for new features and the third for fixes. It helps readers see at a glance how far a new version has moved from the one in your paper.

What should you leave out of the archive?

An archive is permanent, which cuts both ways. Before your first release, check that the repository does not contain credentials, API keys, personal data or large files you do not have rights to share. Removing something from Git history after it has been archived is much harder than keeping it out in the first place. Use a .gitignore for local configuration and keep secrets in environment variables.