nf-core/rnaseq RNA-seq workflow, aligner choices, and limits

What nf-core/rnaseq handles before quantification

nf-core/rnaseq is intended for laboratories and bioinformatics teams analysing RNA sequencing data from organisms that have a reference genome and annotation. It accepts a samplesheet containing FASTQ files or pre-aligned BAM files. From that input, it coordinates read merging, quality control, trimming, contaminant handling, alignment or pseudoalignment, and quantification. The final products include a gene expression matrix, transcript-level results where supported, alignment or coverage files, and a broad quality-control report.

The pipeline is designed for reference-based analysis. It does not present itself as a de novo RNA-seq workflow for organisms without suitable genome and annotation assets. The repository layout also indicates that this is a full workflow rather than a small library: main.nf coordinates subworkflows, workflows, and modules, while nextflow.config and nextflow_schema.json define execution and parameter validation. That structure is useful for teams seeking repeatable containerized processing, but it introduces more operational machinery than a single command-line aligner or quantifier.

The public SRA download feature was removed in version 3.2 and moved into the independent nf-core/fetchngs workflow. That separation reduces responsibility in rnaseq, but users who start from public sequencing data need to obtain or create an accepted samplesheet through another workflow. The README says nf-core/fetchngs can download public samples and auto-create a samplesheet, and can be run with `--nf_core_pipeline rnaseq`.

The nf-core/rnaseq processing chain and alignment routes

The documented data flow begins by merging resequenced FASTQ files. The pipeline can infer strandedness by subsampling reads and pseudoaligning with fq and Salmon, then runs FastQC. UMI extraction with UMI-tools and adapter or quality trimming with Trim Galore! can occur before mapping. BBSplit can remove genome contaminants, while SortMeRNA can remove ribosomal RNA when the relevant route is selected.

The core design choice is the aligner and quantification route. The README lists STAR followed by Salmon, STAR followed by RSEM, and HiSAT2 with no quantification. The STAR implementation can use Sentieon. A separate optional route performs pseudoalignment and quantification with Salmon or Kallisto. Other outputs include transcript assembly and quantification with StringTie, sorted and indexed alignments with SAMtools, UMI-based deduplication, duplicate marking with Picard MarkDuplicates, and bigWig coverage produced through BEDTools and bedGraphToBigWig.

This structure makes the pipeline more than a mapper wrapper, but it means that choosing STAR does not identify one fixed downstream product. STAR can feed either Salmon or RSEM, while an optional Salmon or Kallisto path operates through pseudoalignment rather than the main genomic alignment route. The resulting workflow graph, storage use, and interpretation all depend on those parameters. A reviewer should therefore treat the complete route as the unit under review rather than judging only the selected aligner.

QC choices, optional tools, and RustQC boundaries

nf-core/rnaseq collects QC across read processing, alignment, gene biotype, sample similarity, and strand specificity. MultiQC and R present summary reports. More specific tools include RSeQC, Qualimap, dupRadar, and DESeq2. Preseq is disabled by default and is enabled with `--skip_preseq false`. Optional contamination detection can run Kraken2 followed by Bracken or Sylph on selected screening reads, with unaligned reads selected by default.

The pipeline also offers an experimental RustQC mode. It is described as a single-pass alternative to RSeQC, Qualimap, dupRadar, Preseq, and SAMtools stats, and it is enabled with `--use_rustqc`. The README explicitly recommends trialling it on pilot data first. That wording matters: RustQC is not presented as having the same adoption status as the established QC components. Switching to it changes both execution time and the report set, so the project-specific verification should compare the metrics available in the chosen output against those required by the analysis.

The HiSAT2 route has a firmer boundary. Quantification is not performed because the README states that there is no appropriate option for calculating accurate expression estimates from HiSAT2-derived genomic alignments. The route remains relevant when users prefer that alignment for QC or other downstream analysis compatible with its output. Choosing HiSAT2 merely because it appears among the supported aligners would miss a central functional constraint.

Installing nf-core/rnaseq and preparing a first analysis

The README links to the project documentation at https://nf-co.re/rnaseq and identifies Nextflow and nf-core tooling, but its usage section is truncated before it provides installation or launch commands. For that reason, this article does not invent a command, version selector, parameter file, or sample-sheet schema. The first operational step is to obtain the current installation and usage instructions from the linked documentation, then confirm that the examples match the release selected for analysis.

The repository identifies Nextflow 25.10.4 and nf-core template version 4.1.0 in its documentation, while the recent release history includes nf-core/rnaseq v3.27.0, v3.26.0, and v3.25.0. These labels help distinguish documentation context from a universal installation recipe. A first real analysis still needs three concrete artifacts: a samplesheet representing FASTQ or BAM inputs, a reference genome and matching annotation, and an explicit decision about the aligner, quantification method, strandedness handling, and QC profile.

The README confirms support for Conda, Docker, and Singularity execution environments, as well as launching through Seqera Platform. It does not provide a complete executable example in the available usage section, so selecting an environment should be followed by validation against the documented command for the chosen release. Since no release-pinning flag is shown there, copying a generic nf-core command from elsewhere would risk assuming behavior that the README does not establish.

Alternative approaches to nf-core/rnaseq workflow management

The clearest alternative is to assemble the individual tools documented by nf-core/rnaseq into a custom pipeline. STAR can feed Salmon or RSEM, while Salmon or Kallisto can perform pseudoalignment and quantification. Such an arrangement offers direct control over each stage and can produce a smaller execution graph when only a few outputs are needed. The cost is that the integrator must handle workflow coordination, input consistency, software environments, reporting, and parameter propagation. nf-core/rnaseq packages those concerns into a defined workflow and adds standard QC presentation.

A second practical alternative is to stop after alignment and use that output in another analysis framework. This maps most closely to the documented HiSAT2 option, which does not quantify expression. It is appropriate when the immediate requirement is an alignment and compatible downstream inspection, not a gene expression matrix.

The choice is not simply pipeline versus command line. A small analysis with one aligner and one report may justify a custom script. A multi-sample project requiring trimming, deduplication, several QC views, transcript outputs, coverage, and a consolidated report has a stronger case for nf-core/rnaseq. The relevant comparison is the number of coordinated stages and the need for repeatability, not a generic claim that the packaged workflow is automatically preferable.

Upgrade, compute, and maintenance implications for nf-core/rnaseq

The repository is not archived, and its last push was on 2026-10-15. Recent releases include v3.27.0 on 2026-09-23, v3.26.0 on 2026-05-07, and v3.25.0 on 2026-04-24. Those facts establish recent repository activity and release cadence. They do not remove the upgrade work associated with a workflow that integrates many external bioinformatics tools.

Upgrades can affect tool versions, module structure, parameters, report content, and output layout. The presence of experimental RustQC mode adds another reason to validate changes against a fixed dataset. Pinning analysis to a particular release can make past runs easier to interpret, but the README excerpt does not document the exact upgrade procedure or compatibility policy, so it should not be guessed. Teams need to compare release notes, configuration changes, and expected outputs before moving an established pipeline forward.

Compute and storage requirements are route-dependent. A STAR-to-RSEM workflow, STAR-to-Salmon workflow, pseudoalignment workflow, coverage generation, contamination detection, and extensive QC represent different combinations of memory, temporary disk, reference data, and intermediate files. The README gives no storage figures or runtime targets. Administrators should estimate resources from the selected modules and pilot a representative sample instead of selecting an infrastructure size from the project name alone.

The MIT license identifies the repository as permissively licensed, which generally makes source availability and reuse less restrictive than a copyleft project. This is not legal advice. Reviewers still need to inspect the repository LICENSE file and account separately for the licenses of Nextflow, containerized tools, reference genomes, annotations, and any datasets used in an analysis.

Editorial conclusion

Adopt nf-core/rnaseq when the team can operate Nextflow infrastructure and needs repeatable RNA-seq processing with explicit aligner and quantification choices. Do not choose the HISAT2 route for expression analysis because it produces no quantification, and do not select the experimental RustQC path before checking pilot results. For any release, verify the selected quantification method, strandedness behavior, reference assets, resource requirements, and expected QC outputs. The repository was last pushed on 2026-10-15, and adoption should still be tied to a pinned release with reproducible test data.

Frequently asked questions

Official sources

1. License: MIT
2. nf-core/rnaseq on GitHub
3. Project website
4. README
5. Releases