Skip to main content

Migrating to 26.10

Nextflow 26.10 is scheduled to release in October 2026.

New features​

Global cache​

The global cache is a shared, content-addressable cache backed by cloud storage. It stores all task executions in a single work directory. Whereas -resume only reuses work from a previous run of the same pipeline, the global cache can reuse tasks across different runs.

The global cache is available through Seqera Platform. It supports AWS, Google Cloud, and Azure.

Static typing (out of preview)​

Static typing, introduced as a preview feature in Nextflow 25.10, is no longer in preview. The syntax has not changed since 26.04. Type checking is now available in the Nextflow CLI as well as the language server.

nextflow lint reports type errors for any script that enables nextflow.enable.types. nextflow run warns about type errors but does not fail the run.

Every script that uses typed processes or typed workflows must still enable nextflow.enable.types.

Workflow modules​

The module system now supports workflows as well as processes.

A module is a standalone process or workflow. You publish workflow modules to the Nextflow registry, install them, and include them with the same commands and include syntax as process modules:

// process module
include { BWA_MEM } from 'nf-core/bwa/mem'

// workflow module
include { FASTQ_ALIGN_STAR } from 'nf-core/fastq_align_star'

To depend on other modules, a workflow module declares them in the module spec and includes them in the module script. Installing a workflow module vendors its dependencies under its own modules directory. Two workflows can therefore depend on different versions of the same module without conflict. To change a dependency version, edit it in meta.yml and re-vendor the dependencies with module install -update-deps.

Run a typed workflow module directly with nextflow module run:

# create a typed workflow module
nextflow module create -kind Workflow acme/hello

# run the workflow module
nextflow module run acme/hello --greeting 'Hello world!'

Each take: input becomes a param of the same name. Its declared type determines how Nextflow reads the value. A Channel<E> input takes a CSV, JSON, or YAML samplesheet. Nextflow loads the samplesheet as a channel of records and validates and converts each row against the element type. Nextflow reports each emit: output as a workflow output.

See Modules and Typed parameters for details.

Pipeline composition​

You can include a pipeline and call it like a named workflow. Here, a pipeline is the params block, entry workflow, and output block of a script. The params block acts as the take: section and the output block acts as the emit: section. Use this to compose pipelines with regular dataflow logic.

Given a pipeline:

// pipelines/rnaseq.nf
nextflow.enable.types = true

params {
    input: Channel<Sample>
    aligner: String = 'star_salmon'
    fasta: Path
}

workflow {
    // ...
}

output {
    bams: Channel<Path> { path 'bams' }
    multiqc: Path { path 'multiqc' }
}

Include it with the workflow keyword, name it with an alias, and call it with a record of params:

// main.nf
nextflow.enable.types = true

include { workflow as RNASEQ } from './pipelines/rnaseq.nf'

workflow {
    main:
    rnaseq = RNASEQ(record(
        input: channel.of( /* ... */ ),
        fasta: file('index.fasta')
    ))
    rnaseq.bams.view()      // Channel<Path>
    rnaseq.multiqc.view()   // Value<Path>
}

You can run rnaseq.nf directly from the CLI or include it like a named workflow. When included, it can consume a channel from an upstream pipeline and process each item as soon as the upstream pipeline emits it.

Both the calling script and the included pipeline must enable static typing.

See Pipeline composition for details.

Agents (preview)​

warning

Agents are a preview feature. Their syntax and behavior may change in future releases.

An agent is a process-shaped primitive that wraps an agent run. It declares inputs and outputs, renders a prompt, calls a language model, and emits the result:

// nextflow.config
agent.runner = 'pi'
agent qa {
    model 'openai/gpt-5-mini'
    instruction 'You are a concise scientific assistant.'

    input:
    question: String

    output:
    answer: String

    prompt:
    """
    Answer briefly: ${question}
    """
}

workflow {
    qa('What is FASTQ format?').view()
}

Each agent call runs as a regular Nextflow task, with its own work directory, retries, parallelism, caching, and lineage. You can compose agents with regular dataflow logic, like processes.

See Agents for details.

Enhancements​

Formatter preserves comments​

The Nextflow formatter (nextflow lint -format) now preserves all comments in scripts and config files. Previously, the formatter discarded comments outside of specific locations.

logfile command​

The new logfile command prints a .nextflow.log file, with optional level filtering and follow mode:

$ nextflow logfile kickass_rutherford -level ERROR
$ nextflow logfile last -f

The argument can be a run name, a session ID or a unique prefix of one, last, or a log file.

See the logfile command reference for details.

Accelerator directive for local executor​

The local executor now allocates accelerators such as GPUs to tasks that request them with the accelerator directive. Set the environment variable for your accelerator type to declare which devices are available. See Local executor for details.

Publish targets as a map​

The path directive of a workflow output can return a map of source files to publish targets. This is equivalent to using the >> operator for each pair:

output {
    samples {
        path { sample -> [
            (sample.fastq_1): "fastq/${sample.id}/",
            (sample.fastq_2): "fastq/${sample.id}/"
        ] }
    }
}

You can extract the publish mapping to a shared function, e.g., to reuse it when composing pipelines.

See Workflow outputs for details.

Reports in the output directory​

Use the new directory option in the dag, report, timeline, and trace scopes to save built-in reports to the workflow output directory instead of the launch directory:

report {
    enabled = true
    directory = 'pipeline_info'
}

The path is resolved against outputDir and must be a relative path within it.

Configurable plugin registries​

Nextflow resolves plugins from the public registry at https://registry.nextflow.io by default. Use the registry config scope to configure additional registries. Nextflow tries them in order. See Plugin registry for details.

smolvm container engine​

Nextflow can run tasks in smolvm microVMs. See smolvm for details.

Breaking changes​

  • The -with-weblog run option is no longer supported. Use the nf-weblog plugin instead.

  • The echo process directive was removed. Use debug instead.

  • The Kubernetes executor uses Jobs by default instead of Pods. Set k8s.computeResourceType to Pod to keep the previous behavior.

  • Nextflow writes console output to standard error instead of standard output. This separates log messages from the output of commands such as nextflow config and nextflow run -output-format json.

Cache-breaking changes​

The hash of eval commands has changed. This fixes a bug where tasks with eval outputs did not have a stable hash across runs. As a result, every process with an eval output re-executes on the first resume after upgrading.

Deprecations​

  • The storeDir process directive is deprecated. Use explicit workflow logic to reuse an intermediate output if it is present and compute it otherwise. See storeDir for an example.

  • The seqera.executor.autoLabels config option is deprecated. Use tower.autoLabels instead, which applies to every executor that supports the resourceLabels directive.

  • Machine type selection for Google Batch through the Seqera Cloud Info service is deprecated, along with the NXF_CLOUDINFO_ENABLED environment variable.

Miscellaneous​

On this Page