nf-core/sarek: one Nextflow pipeline for germline and somatic variant calling

The scope is variant calling, but the caller list is unusually long

Sarek is a workflow designed to detect variants on whole genome or targeted sequencing data, and what it offers is not one variant caller but a selection behind a flag. The listed germline and somatic options include ASCAT, CNVkit, Control-FREEC, DeepVariant, freebayes, GATK HaplotypeCaller, GATK Mutect2, indexcov, Lofreq, Manta, mpileup, MSIsensor2, MSIsensor-pro, MuSE, Sentieon Haplotyper, Strelka and TIDDIT. Which caller applies to which data type is not left to guesswork, since the documentation points to a compatibility section under usage. The same philosophy applies to alignment, where you can pick BWA-mem, BWA-mem2, dragmap or Sentieon BWA-mem, and to the copy-number tools. This is the shape of a pipeline built for shared use across groups, and it is also where the decision burden lands on you.

DSL2 with one container per process is the maintainability argument

The pipeline is built on Nextflow, described as a workflow tool to run tasks across multiple compute infrastructures in a very portable manner, and the specific implementation detail is the Nextflow DSL2 model with one container per process. The readme gives the reason plainly, that one container per process makes it much easier to maintain and update software dependencies. Where possible the processes are taken from nf-core/modules, so they are shared with all nf-core pipelines and with the wider Nextflow community rather than being reinvented locally. Around that core sit the usual nf-core conventions visible in the repository tree: a main.nf, a workflows directory, a subworkflows directory, a modules directory with a modules.json, a conf directory, a nextflow.config, a nextflow_schema.json that defines the parameters, and a tower.yml for the Seqera Platform. There is also an nf-test.config, a .pre-commit-config.yaml, a .nf-core.yml file, a ro-crate-metadata.json and a CITATIONS.md file, which is the metadata layer nf-core uses to keep a pipeline citable and machine readable.

The pre-processing steps are parameterised, not assumed

Everything before the caller is a switch. Consensus reads can be formed from UMI sequences with fgbio. Sequencing quality control and trimming runs when you pass --trim_fastq, using FastQC and fastp. Contamination removal uses BBSplit and is enabled with --tools bbsplit. After mapping, the BAM is processed with GATK MarkDuplicates, GATK BaseRecalibrator and GATK ApplyBQSR, or with the Sentieon LocusCollector and Sentieon Dedup pair. Alignment statistics come from samtools stats and mosdepth, and the QC summary is produced with MultiQC. The two flags quoted in the readme, --trim_fastq and --tools, are the pattern to take away, since the pipeline leans on parameter switches rather than on separate branches, and every extra tool you switch on is extra runtime and another container to pull.

An experimental GPU path and a real GPU variant caller

Two GPU entries appear in the summary, and both are marked as experimental. The first is a GPU-accelerated parabricks implementation used as an alternative to the map reads and process BAM steps together, selected with --aligner parabricks. The second is a GPU-accelerated germline calling option, Parabricks HaplotypeCaller, selected with --tools parabricks_haplotypecaller. The framing matters for planning. An experimental flag in an nf-core pipeline is a supported thing to try with a supported way to report problems, but it is not the path the default full-size CI run exercises, so the resource defaults and the benchmarked results for the standard path will not necessarily match what you get. If a GPU path is the reason you are considering Sarek, the honest first step is to run the test profile and compare, rather than to assume the numbers from the standard path carry over.

Consensus across callers, then filtering and annotation

After calling, the pipeline offers a choice between two post-variant calling routes. One applies bcftools view for filtering, with a default of filtering by PASS and the dot, then bcftools norm for normalisation, then bcftools isec for consensus calling, with a default of being called by at least two tools, and bcftools concat for germline VCFs. The other route is Varlociraptor for all VCFs. Variant filtering and annotation then run with SnpEff, Ensembl VEP, BCFtools annotate and SnpSift. The two-caller consensus default is the interesting engineering choice, because calling the same locus with several tools and requiring agreement is a different and more conservative error model than trusting one caller, at the cost of missing variants the others did not find. If you run the pipeline for a large cohort, that trade is worth deciding on purpose rather than inheriting.

A samplesheet in five columns is the whole input contract

The input format is a CSV with a fixed header, and the readme gives a one row example.

patient,sample,lane,fastq_1,fastq_2
ID1,S1,L002,ID1_S1_L002_R1_001.fastq.gz,ID1_S1_L002_R2_001.fastq.gz

Each row represents a pair of fastq files, so the second fastq column is the read two file of a paired end run. The columns are patient, sample, lane, fastq_1 and fastq_2, which means the same patient can appear on several rows with different samples and lanes, and the same sample can be split across lanes, which is how a demultiplexed sequencing facility usually hands data over. Once the sheet exists, the pipeline is run with nextflow. The readme also flags the sensible first move for anyone new to Nextflow and nf-core, which is to follow the environment setup page and test the setup with the -profile test profile before running on real data.

CI on AWS and nf-test are what make the version numbers mean something

The testing story is the part that distinguishes a maintained nf-core pipeline from a script. On release, automated continuous integration tests run the pipeline on a full-sized dataset on AWS cloud infrastructure, and the readme spells out the three things this buys: it confirms the pipeline runs on AWS, it checks that the resource allocation defaults are sensible for real-world datasets, and it allows persistent storage of results so pipeline releases can be benchmarked against each other and against other analysis sources. Those full-size results are published on the nf-core website. There is a separate nf-test badge for unit tests, a linting workflow, and an nf-core template version badge. The release naming also shows a deliberate pattern, with versions named after Norwegian lakes and fjords such as 3.10.0 Aktse, 3.9.0 Sarvesjåhkå and 3.8.1 Laitaure, and the repository is MIT licensed with a CHANGELOG and CITATIONS file. The last push to the repository was on 2026-10-20, so the tree moves with the release line.

Editorial conclusion

Sarek fits a sequencing team that has to run the same germline or tumour analysis repeatedly across species, panels and relapse samples, because the sample sheet, the tool selection and the resource profiles are all parameterised rather than hard coded, and the container per process design removes the dependency management that usually dominates a variant calling setup. It does not fit a one-off analysis on a single sample, where the number of options to decide and the container downloads cost more than the work saves, and it does not fit a group that needs an unusual caller without checking the compatibility table first. Before you run it, follow the Nextflow setup page, test your environment with the -profile test profile, and check the variant calling compatibility documentation for your data type before choosing a tool.

Frequently asked questions

Official sources

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