# Reproducible Bioinformatics Workflows with Containers: Guide By the end of this guide you will be able to build a small containerized bioinformatics workflow with Nextflow, run the identical workflow with Docker on a laptop and with Apptainer on a high-performance computing (HPC) cluster, resume interrupted runs without repeating finished work, capture the exact software version behind every result, and translate the same design into a Snakemake pipeline. You will need a computer with at least 8 GB of RAM, Java 11 or later, Docker Desktop or Docker Engine, about 2 GB of free disk space, and basic terminal skills. The walkthrough builds everything else from an empty directory. The problem this solves is familiar to anyone who has inherited a colleague's scripts. Bioinformatics analyses depend on external software, and each tool follows its own release cycle. Because tools are updated to fix bugs and add features, identical code can produce different results depending on which versions are installed, and incomplete documentation of dependencies undermines reproducibility [1]. Two practices have become the standard answer. A bioinformatics workflow manager describes the analysis as a series of steps and handles execution, and containers package each tool with all of its dependencies into a portable, version-locked unit [2][1]. Used together, they turn a fragile pile of scripts into a pipeline that runs the same way on a laptop, a cluster, and the cloud. ## Why Reproducible Bioinformatics Workflows Need Containers Modern analyses of genomes, transcriptomes, proteomes, and interactomes generate volumes of data that can no longer be processed on a typical desktop computer, so analyses must move between workstations, clusters, and cloud platforms [2]. Every move multiplies the chance that the software stack differs. A mapper updated from version 2.12 to 2.13, a patched system library, or a reinstalled Python package can silently change variant calls, gene counts, or phylogenies. A container solves this by bundling a program with everything it needs to run. Two terms matter here. An image is the immutable package, for example a file that contains FastQC 0.12.1 plus its Java runtime. A container is a running instance of that image. When a workflow pins an image by its versioned tag, the same bits of software execute every time, on any machine that supports the container runtime. Workflow systems and containers are designed to work together. A comparison chapter that implemented the same [evolutionary biology](/blog/guides/evolutionary-biology) analysis with four workflow engines, the Common Workflow Language (CWL), the Guix Workflow Language (GWL), Snakemake, and Nextflow, bundled its tools with the Debian, GNU Guix, and Bioconda software distributions and ran them through container systems such as Docker and Singularity [2]. Those distributions cover the large majority of software packages relevant to biology, including tools such as MAFFT, MrBayes, and BLAST [2]. The practical takeaway is that you rarely need to build container images from scratch, because versioned images and packages for most bioinformatics tools already exist. Containers also serve a community goal beyond any single project. Standardized, shareable pipelines help research comply with the FAIR principles, which stands for Findability, Accessibility, Interoperability, and Reusability, and they make collaboration across groups practical [3]. ## What a Bioinformatics Workflow Manager Does A [workflow management](/knowledge/bioinformatics/snakemake-vs-nextflow-workflow-architectures) system represents, manages, and executes multistep computational analyses [4]. Instead of a shell script that must run top to bottom, you describe each task, its inputs, and its outputs in a structured file, and the manager decides what to run, where to run it, and in what order. The practical benefits are concrete [4]: 1. A common language for describing analyses, which makes workflows readable by other people and reusable as component libraries. 2. Incremental build, meaning the manager reruns only the steps affected by a change. 3. Re-entrancy, meaning you can selectively re-execute parts of a workflow when inputs or configuration change, or resume from where a run stopped. 4. Portability, through support for containers, HPC systems, and clouds. 5. Delegation of execution details, so you focus on what the workflow should do rather than on job scheduling and file plumbing. Several engines can express the same analysis. One teaching project implemented an identical phylogenetics workflow in CWL, GWL, Snakemake, and Nextflow, and ran each of them in parallel [2]. WDL executed by the Cromwell engine is another established option, used for example by a modular Dockerized workflow for Candida genomic surveillance [5]. The differences between engines are mostly syntax and ecosystem, not capability. The end result is a repository where the pipeline definition, configuration, and container choices live under version control. That repository, not a [lab notebook](/knowledge/molecular-biology/lab-notebook), becomes the single source of truth for how results were produced. ## Nextflow vs Snakemake: Choosing a Workflow Manager ![Side-by-side comparison of Nextflow and Snakemake by language, model, container runtimes, ecosystem and first fit.](/article-images/illustrations/reproducible-bioinformatics-workflows-containers-nextflow-snakemake-compare.webp) Nextflow and Snakemake are the two most widely adopted command-line workflow managers in bioinformatics, and both complement graphical platforms such as Galaxy [3]. The nextflow vs snakemake question has no universal answer, so it helps to compare them on structure rather than hype. Nextflow is written in Groovy on the Java Virtual Machine and exposes a purpose-built syntax called DSL2, short for Domain-Specific Language version 2. You define processes, connect them with asynchronous channels, and the runtime resolves execution. Its community ecosystem, nf-core, maintains a large library of shared modules and subworkflows that let groups adopt common standards progressively [3]. Nextflow pipelines run on standalone systems, HPC clusters, and cloud platforms including AWS, Google Cloud, and Azure, and they use container technology such as Docker or Singularity to provision software reproducibly [6]. The model is mature enough for regulated settings, for example a fully containerized clinical Nextflow pipeline for somatic cancer panels that was validated on reference materials and benchmarked on more than two thousand clinical tumor samples [7]. Snakemake uses Python syntax. You define rules with input files, output files, and wildcards, and Snakemake resolves them into a directed acyclic graph (DAG), a tree of jobs with no circular dependencies. Snakemake integrates directly with Conda environments and with containers, and its community maintains reusable wrappers for hundreds of tools [2][8]. | Aspect | Nextflow | Snakemake | |, - |, - |, - | | Implementation language | Groovy on the Java Virtual Machine, with the DSL2 syntax | Python | | Core model | Processes connected by asynchronous channels | Rules with wildcards resolved into a DAG | | Container runtimes | Docker, Podman, Apptainer/Singularity | Apptainer/Singularity, with per-rule container directives, plus Conda deployment | | Community ecosystem | nf-core modules, subworkflows, and pipelines [3] | Snakemake wrappers and shared rule collections [8] | | Execution targets | Laptop, HPC schedulers, Kubernetes, AWS Batch, Google Cloud, Azure [6] | Laptop, HPC schedulers through cluster profiles and executor plugins | | Typical first fit | Production pipelines, clinical settings, community-driven projects | Python-centered labs, incremental data processing, smaller projects | Both systems support incremental builds and containers, so the decision usually comes down to ecosystem and team taste. The most reliable way to choose is to prototype. One research group reimplemented an existing Python analysis workflow inside candidate workflow managers and used those prototypes to evaluate the systems before committing, which surfaced practical differences that documentation alone did not reveal [4]. Budget a day to build the same toy pipeline in both, then pick the one your team can read without complaining. ## Container Runtimes: Docker, Apptainer, and Conda Docker is the container runtime most people meet first. It runs a background service (the daemon) that builds and runs images, and it dominates laptops, continuous integration servers, and cloud deployments. Apptainer, formerly known as Singularity, is the container runtime built for shared HPC systems. It runs unprivileged, meaning a regular user can execute containers without administrator rights, and it converts images into single-file .sif images that behave well on shared filesystems [2]. Because most clusters forbid root access by design, Apptainer is the default container runtime there. Well-engineered tools expose this cleanly, for example a genomics analysis framework that integrates Singularity containers and Anaconda packaging and scaled a 10,305-job analysis across the Open Science Grid, completing in under 2 hours of wall-clock time [9]. Conda, and specifically the Bioconda channel for scientific software, is a lighter alternative. Conda installs versioned packages into isolated environments rather than full containers. Bioconda, together with the Debian and GNU Guix distributions, covers the majority of biology-relevant software [2]. Conda is convenient for development, while containers give stronger guarantees for final, published analyses. Many pipelines support both through configuration profiles, so the same code can run with either deployment method. ## Building a Reproducible Bioinformatics Workflow with Containers, Step by Step This walkthrough builds the smallest complete unit of a [reproducible bioinformatics](/blog/guides/reproducible-bioinformatics-files-environments-parameters-and-provenance) workflow with containers: one Nextflow process that runs FastQC, a standard quality-control tool for FASTQ files (the text format that stores raw sequencing reads and their quality scores), inside a pinned container image. A full pipeline chains many such processes by connecting output channels to input channels, and community module libraries provide hundreds of ready-made containerized processes for exactly that purpose [3]. ### Step 1: Install Nextflow and Docker Confirm Java first, because Nextflow runs on the Java Virtual Machine: ```bash java -version ``` Expected output (your version will differ): ``` openjdk version "17.0.10" 2024-01-16 OpenJDK Runtime Environment ... ``` Install Nextflow into the current directory: ```bash curl -sSL https://get.nextflow.io | bash ./nextflow -version ``` Expected output: ``` N E X T F L O W version 24.10.4 build 5928 ``` The build number will differ on your machine. Any recent release works for this guide. Verify Docker: ```bash docker run --rm hello-world ``` Expected output: ``` Hello from Docker! This message shows that your installation appears to be working correctly. ``` If you plan to run on a cluster, you do not need Docker there. Cluster users will install nothing, because Apptainer is usually already available, as shown in Step 8. ### Step 2: Create Test Data and Project Files Create a project directory and generate two tiny paired FASTQ files so the walkthrough is self-contained: ```bash mkdir -p reproducible-demo/data && cd reproducible-demo bases=$(printf 'ACGT%.0s' $(seq 1 20)) quals=$(printf 'I%.0s' $(seq 1 20)) for r in 1 2 do for i in $(seq 1 100) do printf "@read${i}\n${bases}\n+\n${quals}\n" done | gzip > "data/sample_R${r}.fastq.gz" done ``` This writes 100 identical 80-base reads into `data/sample_R1.fastq.gz` and `data/sample_R2.fastq.gz`. FastQC will finish successfully and note that the sequence content is repetitive, which is expected for synthetic data. Create these files, one per line, in the project directory: ``` main.nf nextflow.config modules/local/fastqc.nf data/sample_R1.fastq.gz data/sample_R2.fastq.gz ``` ### Step 3: Write a Containerized Module Put this in `modules/local/fastqc.nf`: ```groovy process FASTQC { tag "${meta.id}" container 'biocontainers/fastqc:v0.12.1_cv1' input: tuple val(meta), path(reads) output: tuple val(meta), path("*_fastqc.html"), emit: html tuple val(meta), path("*_fastqc.zip"), emit: zip path "fastqc.version", emit: versions script: """ fastqc --version > fastqc.version fastqc --outdir . --threads ${task.cpus} ${reads} """ publishDir "${params.outdir}/fastqc", mode: 'copy', pattern: "*_fastqc.*" } ``` Each line has a job: - `container` pins the exact image. The `biocontainers/fastqc:v0.12.1_cv1` tag comes from the BioContainers project, which publishes versioned images for bioinformatics tools. Never use a floating tag such as `latest`, because the software behind it changes without warning. - `tag "${meta.id}"` labels the task with the sample name in logs. - The input is a tuple of a metadata value and the read files. Nextflow stages those files into an isolated work directory before the container runs. - The three outputs use `emit` names so downstream processes can request one specific output. - `${task.cpus}` passes the allocated CPU count into FastQC. - `publishDir` copies the reports into `results/fastqc`. The `copy` mode duplicates files out of the immutable work directory, which keeps results portable. ### Step 4: Write the Workflow and Configuration Put this in `main.nf`: ```groovy #!/usr/bin/env nextflow nextflow.enable.dsl = 2 include { FASTQC } from './modules/local/fastqc' workflow { reads = channel.fromFilePairs(params.reads, checkIfExists: true) .map { sample, files -> tuple([id: sample], files) } FASTQC(reads) } ``` `fromFilePairs` groups read files by sample using the default `*_{1,2}.*` convention, and `checkIfExists: true` aborts immediately with a clear message if the input files are missing. The `map` line wraps the sample name into a metadata map so the module's `tag` works. Put this in `nextflow.config`: ```groovy params.reads = 'data/*_R{1,2}.fastq.gz' params.outdir = 'results' profiles { docker { docker.enabled = true } singularity { singularity.enabled = true singularity.autoMounts = true } slurm { process.executor = 'slurm' singularity.enabled = true singularity.autoMounts = true } conda { conda.enabled = true } } ``` Profiles switch the deployment method without touching pipeline code. The same module runs with Docker on a laptop, Apptainer on a cluster, or Conda if each module also declares a directive such as `conda 'bioconda::fastqc=0.12.1'`. This one-pipeline-many-profiles pattern is how a single workflow covers standalone systems, HPC, and cloud platforms [6]. ### Step 5: Run the Workflow ```bash nextflow run main.nf -profile docker ``` Expected output (the run name and hash differ every time): ``` N E X T F L O W ~ version 24.10.4 Launching `main.nf` [soggy_einstein] DSL2 - revision: 1a2b3c4d5e executor > local (1) [62/0f9c1a] process > FASTQC (sample) [100%] 1 of 1 ✔ ``` Check the published results: ```bash ls results/fastqc ``` ``` sample_R1_fastqc.html sample_R1_fastqc.zip sample_R2_fastqc.html sample_R2_fastqc.zip ``` Open one HTML file in a browser. It should report the sample name and basic statistics for 100 reads. Then look at the version record the module wrote inside the work directory: ```bash cat work/*/*/fastqc.version ``` ``` FastQC v0.12.1 ``` That single line, produced inside the pinned container, is the software provenance for this step. ### Step 6: Resume, Trace, and Verify the Run Run the same command again with resume enabled: ```bash nextflow run main.nf -profile docker -resume ``` Expected output: ``` [62/0f9c1a] process > FASTQC (sample) [100%] 1 of 1, cached ✔ ``` Nextflow hashes each task's code, inputs, and container image. When nothing changed, the task is reused from cache instead of recomputed. This is incremental build and re-entrancy in practice, and it is what saves hours on a cluster when a late step fails [4]. Produce a machine-readable provenance record: ```bash nextflow run main.nf -profile docker -resume -with-trace head -n 2 pipeline_trace.txt ``` The trace file contains one row per task with columns for status, exit code, and the container image used. The `container` column documents exactly which image produced each result, which is the record you want attached to every analysis. Verify the run with this checklist: 1. The process line ends with a checkmark and reports 1 of 1 tasks. 2. `results/fastqc` contains four files, and the HTML report opens. 3. `fastqc.version` in the work directory shows the expected tool version. 4. A rerun with `-resume` reports the task as cached. 5. `pipeline_trace.txt` lists the container image for the task. ### Step 7: The Same Workflow in Snakemake The same design translates directly. Install Snakemake through Conda: ```bash mamba create -y -n snakemake -c conda-forge -c bioconda snakemake conda activate snakemake snakemake --version ``` You should see a recent release number. Create a file named `Snakefile`: ```python SAMPLES = glob_wildcards("data/{sample}_R1.fastq.gz").sample rule all: input: expand("results/fastqc/{sample}_R{read}_fastqc.html", sample=SAMPLES, read=[1, 2]) rule fastqc: input: "data/{sample}_R{read}.fastq.gz" output: html="results/fastqc/{sample}_R{read}_fastqc.html", zip="results/fastqc/{sample}_R{read}_fastqc.zip" container: "docker://biocontainers/fastqc:v0.12.1_cv1" threads: 1 shell: "fastqc --outdir results/fastqc --threads {threads} {input}" ``` Run it with Apptainer or Singularity as the container runtime: ```bash snakemake -c 2 --use-singularity ``` Expected output (details vary by version): ``` Building DAG of jobs... Rule fastqc: input: data/sample_R1.fastq.gz output: results/fastqc/sample_R1_fastqc.html, results/fastqc/sample_R1_fastqc.zip jobid: 1 2 of 2 jobs done ``` Snakemake resolves the wildcards, builds the DAG, and executes each rule inside its declared container. To inspect the graph, run `snakemake, dag | dot -Tsvg > dag.svg`, which requires Graphviz. To deploy tools through Conda instead of containers, replace the runtime flag with `-use-conda` and add a `conda:` directive to each rule. ### Step 8: Move It to a Cluster On an HPC system with the Slurm scheduler and Apptainer installed, point Nextflow's container cache at scratch storage so images are pulled once per project rather than once per run: ```bash export NXF_SINGULARITY_CACHEDIR=/scratch/$USER/nextflow_singularity nextflow run main.nf -profile slurm -resume ``` Nextflow converts the Docker image into a .sif file, stores it in the cache directory, and submits each task as a Slurm job. No administrator rights are involved, which is exactly why Apptainer became the container standard on shared systems [2]. The same pipeline, unchanged, can target cloud batch services by adding the matching profile [6]. ### When the Run Fails ![Decision tree sorting four common Nextflow and Snakemake failures into their exact error messages and fixes.](/article-images/illustrations/reproducible-bioinformatics-workflows-containers-run-failure-triage.webp) These four errors account for most first-day failures, with their exact messages and fixes. 1. Docker daemon not running. Nextflow reports the underlying Docker error, which reads `Cannot connect to the Docker daemon at unix:///var/run/docker.sock. Is the docker daemon running?`. Start Docker Desktop or the Docker service, then rerun with `-resume` so finished tasks are not repeated. 2. Missing `-profile`. Without a profile, Nextflow runs the script in your local shell, and you see `fastqc: command not found` even though the module declares a container. Fix: always pass `-profile docker`, `-profile singularity`, or another profile. 3. Wrong or missing input files. Snakemake fails with `MissingInputException` and names the file, for example `Missing input files for rule fastqc: data/sample_R1.fastq.gz`. Fix: check the path and the glob pattern. Nextflow with `checkIfExists: true` aborts during channel creation and names the missing file. 4. Bad image tag. Docker prints `Unable to find image '...' locally` followed by a manifest error. Fix: open the image's registry page, confirm the exact tag including the version suffix, and correct the `container` directive. ### Key Options at a Glance | Option | Tool | What it does | |, - |, - |, - | | `-profile docker` | Nextflow | Runs every process inside its declared Docker image | | `-profile slurm` | Nextflow | Submits tasks to the Slurm scheduler with Apptainer containers | | `-resume` | Nextflow | Reuses cached outputs for tasks whose code, inputs, and image are unchanged | | `-with-trace` | Nextflow | Writes `pipeline_trace.txt` with status, exit code, and container per task | | `-with-report` | Nextflow | Writes an HTML report of resource usage for the run | | `-c 2` | Snakemake | Runs up to 2 jobs in parallel | | `-use-singularity` | Snakemake | Executes rules with container directives in Apptainer/Singularity | | `-use-conda` | Snakemake | Deploys rule dependencies through Conda environments | | `mode: 'copy'` | Nextflow `publishDir` | Copies results out of the immutable work directory instead of symlinking | ## Reproducible Bioinformatics Workflow Tips 1. Pin every version. Use image tags that include the tool version, pin Conda package versions, and record reference dataset versions. Identical code with different installed versions produces different results, which is the core failure mode containers exist to prevent [1]. 2. Emit a version record from every process. The `fastqc.version` file in Step 3 is the minimal pattern. Community pipelines collect these per-task records into a single software versions report, which is one of the standards that nf-core enforces across its modules and pipelines [3]. 3. Keep one pipeline, many profiles. Define docker, singularity, and cloud profiles in configuration so the identical code runs everywhere, which is how Nextflow pipelines span standalone systems, HPC clusters, and clouds [6]. 4. Cache container images on shared storage. Set `NXF_SINGULARITY_CACHEDIR` on clusters so a hundred concurrent jobs trigger one image pull instead of a hundred. 5. Develop with resume enabled. Incremental build and re-entrancy let you rerun only affected steps while tuning parameters, and they turn crashes into pauses rather than restarts [4]. 6. Validate before you compute. Check that the environment, inputs, and runtime configuration are what the pipeline expects before the first task runs, and repeat those checks at runtime, a systematic practice recommended for robust pipeline development [8]. 7. Separate compute tasks from glue. Design modules with well-defined task interfaces and explicit input and output specifications, and keep adaptation code apart from the scientific steps. This reinterpretation of software engineering principles improves reuse and maintainability of pipelines [8]. 8. Reuse community components. Search nf-core modules before writing a Nextflow process, and Snakemake wrappers before writing a rule [8][3]. A maintained, containerized, tested module is usually better than a fresh one. 9. Test with small data in continuous integration. Keep a tiny synthetic dataset in the repository and run the pipeline on it automatically for every change, using both real and synthetic test data as recommended practice [8]. A quick-start local test bundled with the workflow, such as the two-sample test dataset shipped with a Dockerized WDL/Cromwell surveillance pipeline, lets any user verify installation in minutes [5]. 10. Archive provenance with results. Store the trace file, the run report, the version records, and the exact pipeline revision (a Git commit hash) alongside the outputs. FAIR-oriented research software guidelines treat these engineering practices as part of making software itself reusable and sustainable [8]. ## Common Mistakes and Limitations 1. Using floating versions. A `latest` image tag or an unpinned Conda install reintroduces the exact problem containers solve, because the software changes under you. Pin tags and package versions everywhere. 2. Assuming Docker works everywhere. Most HPC systems prohibit the Docker daemon because it requires root. Plan an Apptainer or Singularity profile from the start, since that runtime was designed for unprivileged execution on shared systems [2]. 3. Writing outside the work directory. Scripts that write to absolute paths or to the home directory break resume, break portability, and can corrupt concurrent runs. Stage all inputs, write all outputs to the task directory, and publish deliberately. 4. Never testing failure and resume. A pipeline that has only ever run start to finish has untested code paths. Kill a run halfway, restart with `-resume`, and confirm the finished tasks are cached. 5. Treating containers as the whole story. Containers lock software versions, but reproducibility also depends on input data, reference datasets, and parameter values. Version those in the repository too, or the containerized pipeline still cannot be repeated exactly. 6. Skipping input validation. A workflow that accepts any file will eventually produce plausible results from the wrong data. Environment, input, and runtime validation checks exist precisely to catch this before it reaches a report [8]. 7. Building everything from scratch. Rewriting standard steps wastes time and adds bugs. Prototype first to choose the right workflow system for your team, then adopt community modules rather than reimplementing them [4][8]. 8. Underestimating the expertise barrier. Containerization demands technical knowledge and has lacked a standard operating procedure, which is why frameworks that generate ready-to-run, version-locked interfaces exist and why community pipelines with preconfigured profiles are the fastest route for new groups [1]. Two limitations deserve plain language. First, containers capture software, not biology. Results still depend on data quality, parameter choices, and reference data, so those decisions must be documented in the repository. Second, long-term reproducibility depends on the images staying available, so archive the exact image files or digests your results depend on, not just the tag names. ## Frequently Asked Questions ### What is a bioinformatics workflow manager? A bioinformatics workflow manager is software that represents, manages, and executes multistep computational analyses from a structured description of tasks, inputs, and outputs. It gives analyses a common language, supports incremental builds and selective re-execution, and delegates job execution to the tool rather than to hand-written scripts [4]. ### Nextflow vs Snakemake: which should I learn first? Learn the one your collaborators use, and prototype a toy pipeline in both if no one has a preference. Nextflow has the nf-core ecosystem of shared modules and pipelines, while Snakemake offers Python syntax and a large wrapper collection, and both handle containers and HPC execution well [8][3][4]. ### Do containers really make an analysis reproducible? Containers make the software layer reproducible by executing version-locked images, which removes version drift between machines [1]. Full reproducibility also requires versioned input data, reference files, and parameters, recorded alongside the container choices. ### Can I run containerized workflows on an HPC cluster without administrator rights? Yes. Apptainer, formerly Singularity, was built for exactly this, running containers unprivileged on shared systems, and workflow managers integrate it through a profile so the same pipeline runs on a laptop and a cluster [2][6]. ### What is nf-core? nf-core is a community that builds and maintains Nextflow pipelines with shared modules and subworkflows, which lets research groups adopt common standards progressively and gives biologists documented, containerized, FAIR-aligned pipelines they can run from the command line or a web interface [3][6]. ### How do I record the software versions behind my results? Have each process write a version record from inside its container, enable the workflow's trace or report output so every task logs its container image, and archive those files with the results. Systematic validation and version documentation are recommended parts of pipeline development [8]. ### Do I need to learn Groovy or Python first? No. You can run and configure existing pipelines without either language, and the module patterns are simple enough to copy and adapt. Learning to read Groovy helps for Nextflow customization and Python helps for Snakemake, but neither is a prerequisite for the first week. ### How small can a first containerized workflow be? One process is enough, and the FastQC example in this guide is a complete, runnable unit with a pinned container, published outputs, a version record, and resume support. Add a second process only when you need to chain outputs, or adopt a ready-made community module for that step [3]. ## Sources 1. [FairFlow: A transparency-first framework for verifiable and reproducible bioinformatics.](https://pubmed.ncbi.nlm.nih.gov/42800986/) 2. [Scalable Workflows and Reproducible Data Analysis for Genomics.](https://pubmed.ncbi.nlm.nih.gov/31278683/) 3. [Empowering bioinformatics communities with Nextflow and nf-core.](https://pubmed.ncbi.nlm.nih.gov/40731283/) 4. [Using prototyping to choose a bioinformatics workflow management system.](https://pubmed.ncbi.nlm.nih.gov/33630841/) 5. [rMAP-Candida: a modular Dockerized WDL/Cromwell workflow for reproducible Candida species typing, assembly-contiguity assessment, antifungal-resistance marker screening, and phylogenomic surveillance.](https://pubmed.ncbi.nlm.nih.gov/42656346/) 6. [The Nextflow nf-core/metatdenovo pipeline for reproducible annotation of metatranscriptomes, and more.](https://pubmed.ncbi.nlm.nih.gov/41368505/) 7. [ClinBioNGS: A Clinical Bioinformatics Pipeline for Integrated Analysis of Somatic Next-Generation Sequencing Cancer Panels.](https://pubmed.ncbi.nlm.nih.gov/41505665/) 8. [Software engineering for reproducible pipeline development in bioinformatics.](https://pubmed.ncbi.nlm.nih.gov/42756310/) 9. [ScriptManager: a platform for scalable and reproducible high-resolution analysis of genomics datasets.](https://pubmed.ncbi.nlm.nih.gov/42367925/)