Reproducibility Infrastructure: Workflows, Containers, and Code Sharing

A journal accepting a data availability statement, or a funder ticking off “open science” on a grant checklist, does not by itself make a computational result reproducible. Reproducibility is infrastructure, not a sentence in a manuscript. It requires three separable things to exist and to be preserved together: a machine-readable record of what analytical steps were run and in what order, a captured copy of the software environment those steps ran in, and a durable, citable identity for the code itself, independent of any one hosting account. This guide is written for research offices, RDM staff, and research computing support who need to know what to ask a PI or research software engineer to produce — not how to write the pipeline code themselves.

For the distinct question of citing/describing data for reuse, see How to Write a Data Availability Statement for Reproducibility. This guide covers the parallel infrastructure for code and computational workflow.

What “computational reproducibility” actually requires

CASRAI’s Dictionary defines computational reproducibility narrowly and operationally: obtaining the same numerical outputs from the same data and code, on a comparable computational environment. That definition is deliberately narrow — it’s a necessary but limited condition, distinct from the related concepts of methods reproducibility, results reproducibility, empirical reproducibility, and inferential reproducibility. Even within that narrow, computational sense, three separate layers of infrastructure have to be present:

1. Workflow logic — a machine-readable record of the analytical steps and their dependencies, so the pipeline can be re-executed rather than manually reconstructed from a paper’s prose Methods section.
2. Computational environment — the operating system, language runtime, and exact library/package versions the workflow ran against, captured well enough to reconstruct on different hardware.
3. Durable code identity — a copy of the code, and a persistent identifier for that exact version, that survives independently of whether the original GitHub/GitLab account, repository, or branch still exists.

Missing any one layer breaks the chain. A workflow file with no pinned environment can drift as dependencies update. A pinned container with no workflow definition is a black box you can run but not inspect or re-execute in parts. Code on a live repository with no archival deposit can vanish if an account lapses, a repository is renamed, or history is force-pushed — a working link today is not evidence of anything in five years.

Layer 1: Workflow managers — capturing the analysis logic

A workflow manager expresses a pipeline as a set of steps with explicit inputs, outputs, and dependencies, from which it infers a directed acyclic graph (DAG) of jobs. The output is a versionable file that can be re-run, rather than a paragraph of prose that a reader has to reconstruct by hand. Three tools account for most current use in research settings:

• Snakemake — a Python-based system where rules are declared with inputs/outputs and a shell or script body; Snakemake infers the DAG from how those rules connect. It integrates with conda environments and containers directly, and supports cluster and cloud execution.
• Nextflow — built on dataflow programming with a Groovy-based DSL; processes communicate via typed channels, giving implicit parallelism that scales from a laptop to an HPC cluster to the cloud without rewriting the pipeline. The nf-core community maintains a large set of peer-reviewed, curated Nextflow pipelines, mostly in genomics/bioinformatics.
• Common Workflow Language (CWL) — a vendor-neutral, YAML-based specification (not a single tool) designed explicitly for portability across execution engines. It’s more verbose than Snakemake or Nextflow for a solo researcher, but that portability is exactly why it shows up more often in large consortia and regulated settings where a pipeline needs to run identically on infrastructure the original author doesn’t control.

Which tool a lab uses matters less, from a research-administration standpoint, than whether a workflow definition exists at all and is versioned alongside the code. The operational question for a research office to ask is not “which workflow manager?” but “is there a workflow file in the deposited repository, or only a Methods section describing what was done?”

Layer 2: Containers — capturing the computational environment

A container image is a packaged, immutable filesystem and configuration bundling an application with all its dependencies, runnable identically on any compatible container engine — distinct from a virtual machine image (heavier, less portable) and from a conda or renv environment file (which pins package versions but not the operating system or runtime itself). Two container engines dominate research use:

• Docker — the general-purpose, industry-standard container runtime. Widely used, but its default daemon model typically requires root-level privileges, which creates friction on shared, multi-tenant HPC systems that won’t grant that.
• Apptainer (formerly Singularity) — purpose-built for HPC and scientific computing. The project was renamed from Singularity to Apptainer in November 2021 when it joined the Linux Foundation, resolving a naming conflict after a commercial fork (Sylabs) had also kept the Singularity name; the singularity command still works as a backward-compatible alias. Apptainer doesn’t require a root daemon at runtime and can run Docker-format images directly, which is why it’s the more common choice on shared university and national HPC clusters.

A detail that matters more than it looks: a container referenced by a mutable tag (e.g. latest) is not equivalent, for reproducibility purposes, to one referenced by its content digest. Tags can be overwritten to point at a different image later; a digest cannot. A reproducibility-grade container reference is pinned by digest, not by tag alone.

Containers alone don’t guarantee bit-identical results even when correctly pinned. Hardware-dependent floating-point behaviour, non-deterministic multi-threaded execution order, and any network calls made during a run can all still break exact reproducibility inside an otherwise-correct container — this is a known, common failure mode, not a hypothetical edge case, and it’s a reasonable thing for a research office to flag to a PI who assumes “we containerized it” ends the conversation.

Layer 3: Making the code discoverable, citable, and durable

A live repository on GitHub or GitLab is a development and collaboration tool, not an archive. It can be deleted, renamed, transferred, or rewritten by a force-push, and an account tied to a graduating student or a closed grant is a real, common failure point. A GitHub mirror that automatically syncs from an upstream source is a different thing again — useful for visibility, but the upstream typically remains the canonical copy, not a preservation strategy in itself. Durable code identity requires a deliberate archival step, and in practice this means one or both of the following:

• Zenodo — a free generalist repository operated by CERN under OpenAIRE. Its GitHub integration lets a depositor link their GitHub account, toggle archiving on for a specific repository, and have every subsequent GitHub release automatically pulled into Zenodo and assigned a DataCite DOI. If the repository contains a CITATION.cff file (a YAML-based, human- and machine-readable citation-metadata format) in its root, Zenodo reads it to populate the deposit’s author/title/version metadata automatically; if both a CITATION.cff and a .zenodo.json file are present, Zenodo uses .zenodo.json and ignores the CFF file for that deposit.
• Software Heritage — an independent, continuously operating archive (not release-triggered like Zenodo’s GitHub integration) that crawls and preserves public source-code repositories at very large scale. Every artefact it archives receives a SoftWare Hash IDentifier (SWHID) — an intrinsic identifier computed from the object’s own content via cryptographic hashing, which resolves permanently within the archive even if the original repository is later deleted or its history rewritten. SWHID was published as an ISO/IEC international standard (ISO/IEC 18670) on 23 April 2025.

Zenodo and Software Heritage are complementary, not redundant. Zenodo mints a citable DataCite DOI tied to a specific release, the currency researchers and citation tools already expect. Software Heritage provides content-addressed, hash-based long-term preservation independent of any release workflow or account. A reproducibility-grade code deposit reasonably uses both rather than treating them as alternatives.

Software citation and metadata standards

Two standards efforts specifically extend citation and FAIR practice to software, distinct from the data-citation and DOI infrastructure most research offices already know:

• The FORCE11 Software Citation Principles (published 2016) set out six principles for citing software as a legitimate research product: importance, credit and attribution, unique identification, persistence, accessibility, and specificity. CASRAI’s Dictionary covers this working group directly under Software citation (Software Citation Working Group).
• The FAIR4RS Principles (FAIR for Research Software, v1.0, approved by the Research Data Alliance in June 2022) adapt the original FAIR data principles — Findable, Accessible, Interoperable, Reusable — to the specific realities of software, which unlike a static dataset has versions, dependencies, and an executable form that a document metadata schema alone doesn’t capture well.

Metadata packaging formats worth knowing about even if a research office never edits them directly: CodeMeta (a schema.org-based crosswalk for software metadata) and RO-Crate (Research Object Crate, a lightweight JSON-LD packaging convention for bundling a dataset or workflow together with its metadata, with CodeMeta as its software-specific extension). Their practical relevance for a research administrator is narrow but real: when a funder or repository asks whether a deposit is “FAIR4RS-compliant” or machine-readable, these are the formats that claim usually rests on.

Where this shows up in research-administration workflows

Software Management Plans. A Software Management Plan (SMP) is a structured plan covering how research software will be developed, documented, licensed, tested, released, and maintained over a project’s lifetime — increasingly required alongside, or as an extension of, a Data Management Plan (Horizon Europe projects, for example, may be required to produce both as separate formal deliverables). A real SMP names a specific deposit target (Zenodo, Software Heritage, or both), a versioning approach, and a license — a GitHub README with no further plan, or a DMP that merely mentions a single repository link, does not satisfy the intent of an SMP requirement.

Code availability statements at submission. A code availability statement is a published statement of where a study’s source code can be obtained, under what license, and at what version. A strong one references both a working repository (for ongoing development) and a durable archive with a version or commit identifier and explicit licensing terms — “available on reasonable request” with no archive reference is the pattern journal policies increasingly treat as insufficient on its own, mirroring the same shift already established for data-availability statements (see the companion guide above).

Peer verification of artefacts. The ACM’s Artifact Review and Badging policy is a separate, complementary mechanism to a code-availability statement: it defines badges an independent reviewer can award after actually attempting to run the provided materials — Artifacts Evaluated – Functional (the artifact is documented, complete, and exercisable), Artifacts Evaluated – Reusable (exceeds minimal functionality and is properly packaged for reuse by others), and Results Reproduced (an independent team obtained the paper’s main results using the author-supplied artifacts). These badges only mean something if the underlying workflow, environment, and code are actually available in the first place — they’re a verification layer sitting on top of the three infrastructure layers above, not a substitute for them.

A practical checklist for a research office

When reviewing a project’s code-sharing plan, a deposited software release, or a code availability statement, it’s reasonable to ask whether it specifies:

• A workflow definition file (Snakemake, Nextflow, CWL, or equivalent) — not only a prose description of the analysis steps.
• A pinned computational environment — a container image referenced by digest, or an equivalent lockfile (conda, renv, or similar) alongside it.
• An explicit, named software license — absence of a license is not the same as permission to reuse.
• A deposit in at least one durable archive (Zenodo for a DataCite DOI, Software Heritage for hash-based long-term preservation, ideally both) — not only a live repository URL.
• A machine-readable citation file (CITATION.cff or equivalent) so the deposit’s metadata doesn’t depend on someone manually re-typing author and version information correctly.

None of this requires a research office to write or review code itself. It requires knowing which of these five items is missing from what’s actually been submitted, which is a checklist problem, not a technical one.

Frequently asked questions

Is a GitHub repository enough to satisfy a code-sharing requirement?

Not on its own. A live repository is a development and collaboration surface, not an archive — it can be deleted, renamed, or made inaccessible if an account lapses. Satisfying a durable code-sharing requirement means pairing the working repository with an archival deposit that assigns a persistent identifier, such as a Zenodo DOI or a Software Heritage SWHID.

Do I need both a workflow manager and a container?

Generally yes, because they solve different problems. A workflow manager without a pinned environment can still drift as dependencies update over time. A container without a workflow definition is a runnable black box that can’t be inspected or re-executed step by step. Reproducibility infrastructure typically needs both layers, not either one alone.

Does putting code in a container guarantee bit-identical results?

No. A correctly pinned container captures the software environment, but hardware-dependent floating-point behaviour, non-deterministic multi-threaded execution, and network calls made during a run can all still produce different outputs on different hardware even with an identical container image. Containers make computational reproducibility achievable, not automatic.

Is Software Heritage a replacement for Zenodo, or the other way around?

Neither replaces the other — they’re complementary. Zenodo mints a DataCite DOI tied to a specific, citable release, which is the identifier researchers and citation managers already expect. Software Heritage continuously archives public source code at very large scale and assigns a content-addressed SWHID that resolves permanently even if the original repository disappears. A reproducibility-grade deposit reasonably uses both.

What’s the difference between a Software Management Plan and a Data Management Plan?

A DMP addresses research data; a Software Management Plan addresses the software/code produced by a project specifically — licensing, versioning, testing, release process, and long-term sustainability. Some funders (Horizon Europe, notably) may require both as separate deliverables rather than treating a brief software mention inside a DMP as sufficient.

For the data-management side of this same infrastructure question, see How to Write a Data Availability Statement for Reproducibility and the Research Data Management pillar. For repository selection more broadly, see How to Choose an Open Data Repository.