Containers Rot Too

What happens when you try to rebuild containerized bioinformatics tools from five years of software papers

I recently wrote about our SNIFF paper in PLOS Computational Biology: tips for deciding whether someone else’s scientific software is worth building an analysis on.

How to SNIFF out Good Scientific Software

The last of the five features was fragility. In theory, a container is supposed to make that question moot. I.e., you package the dependencies, freeze them at build time, and the tool runs the same way years later. In theory.

Excerpt from the SNIFF framework, which organizes ten quick tips for evaluating scientific software sustainability and security into five complementary dimensions: Source, Network, Interaction, Fit, and Fragility. Adapted from Nagraj et al 2026 PLOS Computational Biology 22(7): e1014510. CC-BY.

Our new preprint, led by VP Nagraj, tests whether that promise holds.

Nagraj VP, Turner SD, Magee N. Survey and Evaluation of Applied Containerization Practices in Bioinformatics. bioRxiv, 2026.07.17.739198. https://doi.org/10.64898/2026.07.17.739198.

We pulled 252 containerized bioinformatics tools from software papers published between 2021 and 2025, annotated how each one was built and maintained, then tried to rebuild and pull every image on a purpose-built Kubernetes platform, socr8s. Which, by the way, we made available at github.com/vpnagraj/socr8s (MIT).

Of the 195 tools with a build specification, only 50 rebuilt successfully. That’s only 26%, even after we retried failures to correct for build-context mismatches and transient network drops! The single strongest predictor of a successful build was not multi-stage builds, pinned parent images, or multi-architecture support. It was recent commit activity. Tools with a commit in the preceding two years were about twice as likely to build (OR 2.26, 95% CI 1.16-4.42).

Build success stratified by containerization practices for the n=195 tools with build specifications. For tools with multiple component images, build success status was only. Table from Nagraj, Turner & Magee (2026), CC-BY 4.0.

Commit activity for the tools with a build specification, one row per tool, each tile a month shaded by that month’s share of total commits. Tools that built successfully (bottom) skew their activity toward recent months; tools that failed (top) tail off earlier. The dashed line marks two years before data retrieval. Figure from Nagraj, Turner & Magee (2026), CC-BY 4.0.

Pre-built images held up better. Of 173 images documented on a public registry, all but 3 pulled cleanly. A registry copy is a real safeguard, but it preserves a tool exactly as it was pushed, so any security patch or compatibility fix means rebuilding from a specification file that may no longer work.

Across all 252 tools, 24% could neither be rebuilt nor pulled. I.e., there is no straightforward path back to a working tool for a quarter of the sample.

We used AI once, to triage build-failure logs with a Claude skill, and we manually re-audited its classifications and reassigned several. The failures were mostly bitrot: broken dependency chains, vanished parent images, repository restructuring that left COPY targets missing. Of the 10 failures the skill flagged as trivial to fix, we resolved 5 on the first try. The rest surfaced a second problem once we cleared the first.

Data, analysis code, and the preprint’s Quarto source files are here on GitHub.

⁂

TL;DR: Containerizing a tool is necessary but not sufficient. Without an update or a new commit now and then, the image slides toward the rot and irreproducibility that the container was meant to prevent. I.e., the fragility signal from SNIFF.