Migrating to 25.10

Nextflow 25.10 was released on October 22, 2025.

New features

Workflow params

The params block is a new way to declare pipeline parameters in a Nextflow script:

params {
    // Path to input data.
    input: Path

    // Whether to save intermediate files.
    save_intermeds: Boolean = false
}

workflow {
    println "params.input = ${params.input}"
    println "params.save_intermeds = ${params.save_intermeds}"
}

This syntax allows you to declare all parameters in one place with explicit type annotations, and it allows Nextflow to validate parameters at runtime.

See Parameters for details.

Workflow outputs (out of preview)

Workflow outputs, introduced in Nextflow 24.04 as a preview feature, have been brought out of preview and can now be used without the nextflow.preview.output feature flag.

The final version adds the ability to specify a type annotation for each output declaration:

workflow {
    main:
    ch_samples = // ...

    publish:
    samples = ch_samples
}

output {
    samples: Channel<Map> {
        path '.'
        index {
            path 'samples.csv'
        }
    }
}

See Migrating to workflow outputs to get started.

Type annotations

Type annotations are a way to denote the type of a variable. They help document and validate pipeline code.

workflow RNASEQ {
    take:
    reads: Channel<Path>
    index: Value<Path>

    main:
    samples_ch = QUANT( reads, index )

    emit:
    samples: Channel<Path> = samples_ch
}

def isSraId(id: String) -> Boolean {
    return id.startsWith('SRA')
}

// feature flag required for typed processes
nextflow.preview.types = true

process fastqc {
    input:
    (id, fastq_1, fastq_2): Tuple<String,Path,Path>

    output:
    logs = tuple(id, file('fastqc_logs'))

    script:
    """
    mkdir fastqc_logs
    fastqc -o fastqc_logs -f fastq -q ${fastq_1} ${fastq_2}
    """
}

The following declarations can be annotated with types:

  • Pipeline parameters (the params block)

  • Workflow takes and emits

  • Process inputs and outputs

  • Function parameters and returns

  • Local variables

  • Closure parameters

  • Workflow outputs (the output block)

Type annotations can refer to any of the standard types.

Some types use generic type parameters to work with different data types in a type-safe way. For example:

  • List<E> and Channel<E> use the generic type E to specify the element type in the list or channel

  • Map<K,V> uses the generic types K for the key type and V for the value type in the map

The following examples show types with type parameters:

// List<E> where E is String
def sequences: List<String> = ['ATCG', 'GCTA', 'TTAG']

// List<E> where E is Path  
def fastqs: List<Path> = [file('sample1.fastq'), file('sample2.fastq')]

// Map<K,V> where K is String and V is Integer
def readCounts: Map<String,Integer> = [sample1: 1000, sample2: 1500]

// Channel<E> where E is Path
def ch_bams: Channel<Path> = channel.fromPath('*.bam')

Type annotations can be appended with ? to denote values can be null:

def x_opt: String? = null

In the type system, queue channels are represented as Channel, while value channels are represented as Value. To make the terminology clearer and more concise, queue channels are now called dataflow channels (or simply channels), and value channels are now called dataflow values. See Dataflow for more information.

Note

Nextflow supports Groovy-style type annotations using the <type> <name> syntax, but this approach is deprecated in strict syntax. While Groovy-style annotations remain valid for functions and local variables, the language server and nextflow lint automatically convert them to Nextflow-style annotations during code formatting.

See Migrating to static types for details.

Auth and Launch commands

The Nextflow CLI has two new commands: nextflow auth and nextflow launch. Together, they allow you to authenticate with Seqera Platform and launch pipelines from the command line. This approach streamlines the previous workflow of using nextflow run with the -with-tower option.

# Authenticate with Seqera Cloud
nextflow auth login

# Check authentication status
nextflow auth status

# Configure Seqera Platform settings
nextflow auth config

# Launch a pipeline in Seqera Platform
nextflow launch nextflow-io/hello

See auth and launch for details.

Enhancements

Nextflow plugin registry

Nextflow now uses the Nextflow plugin registry to download plugins in a more efficient and scalable manner.

The legacy plugin index can still be used by setting the NXF_PLUGINS_REGISTRY_URL environment variable:

export NXF_PLUGINS_REGISTRY_URL="https://raw.githubusercontent.com/nextflow-io/plugins/main/plugins.json"

Note

Plugin developers will not be able to submit PRs to the legacy plugin index once the plugin registry is generally available. Plugins should be updated to publish to the Nextflow plugin registry using the Nextflow Gradle plugin instead. See Nextflow plugin registry for details.

New syntax for workflow handlers

The workflow onComplete and onError handlers were previously defined by calling workflow.onComplete and workflow.onError in the pipeline script. You can now define handlers as onComplete and onError sections in an entry workflow:

workflow {
    main:
    // ...

    onComplete:
    println "workflow complete"

    onError:
    println "error: ${workflow.errorMessage}"
}

This syntax is simpler and easier to use with the strict syntax. See Workflow handlers for details.

Simpler syntax for dynamic directives

The strict syntax allows dynamic process directives to be specified without a closure:

process hello {
    queue (entries > 100 ? 'long' : 'short')

    input:
    tuple val(entries), path('data.txt')

    script:
    """
    your_command --here
    """
}

Dynamic process settings in configuration files must still be specified with closures.

See Dynamic directives for details.

Configurable date formatting

You can now customize the date and time format used in notifications, reports, and console output using the NXF_DATE_FORMAT environment variable:

# Default format
# e.g., 11-Aug-2016 09:40:20

# Use ISO format with timezone
export NXF_DATE_FORMAT="iso"
# e.g., 2016-08-11T09:40:20+02:00

# Use custom format
export NXF_DATE_FORMAT="yyyy-MM-dd HH:mm"
# e.g., 2016-08-11 09:40

This feature addresses previous inconsistencies in timestamp representations.

Breaking changes

  • The google-lifesciences executor is no longer supported because the Google Cloud Life Sciences API was discontinued in July 2025. Use the google-batch executor instead.

  • The AWS Java SDK used by Nextflow was upgraded from v1 to v2, which introduced some breaking changes to the aws.client config options. See the guide for details.

  • The nextflow.config.schema package was renamed to nextflow.config.spec. Plugin developers that define custom configuration scopes will need to update their imports accordingly.

Deprecations

  • The legacy type detection of CLI parameters is disabled when using the strict syntax (NXF_SYNTAX_PARSER=v2). Legacy parameters in the strict syntax should not rely on legacy type detection. Alternatively, use the new params block to convert CLI parameters based on their type annotations. Legacy type detection can be disabled globally by setting the environment variable NXF_DISABLE_PARAMS_TYPE_DETECTION=true.

  • The use of workflow handlers in the configuration file has been deprecated. You should define workflow handlers in the pipeline script or a plugin instead. See Workflow handlers for details.

  • The nextflow.enable.configProcessNamesValidation feature flag is deprecated. It was originally introduced to suppress false warnings for process selectors targeting conditional processes. The strict syntax now validates process selectors without producing false warnings.

Miscellaneous

  • New config option: docker.registryOverride

  • New config options: wave.build.compression.*

  • New executor: Fujitsu Technical Computing Suite (tcs)

  • Support Java 25