(migrating-25-10-page)=

# Migrating to 25.10

[Nextflow 25.10](https://github.com/nextflow-io/nextflow/releases/tag/v25.10.0) was released on October 22, 2025.

## New features

<h3>Workflow params</h3>

:::{note}
Typed parameters require the {ref}`strict syntax <strict-syntax-page>`. Set the `NXF_SYNTAX_PARSER` environment variable to `v2` to enable:

```bash
export NXF_SYNTAX_PARSER=v2
```
:::

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

```nextflow
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 {ref}`workflow-typed-params` for details.

(workflow-outputs-final)=

<h3>Workflow outputs (out of preview)</h3>

{ref}`Workflow outputs <workflow-output-def>`, introduced in Nextflow 24.04 as a preview feature, have been brought out of preview.

If you were using a preview version of workflow outputs, you must remove the `nextflow.preview.output` feature flag when upgrading to Nextflow 25.10. Setting this feature flag in 25.10 will cause your pipeline to fail.

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

```nextflow
workflow {
    main:
    ch_samples = // ...

    publish:
    samples = ch_samples
}

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

See {ref}`migrating-workflow-outputs` to get started.

(static-typing-first-preview)=

<h3>Static typing (preview)</h3>

:::{note}
Static typing requires the {ref}`strict syntax <strict-syntax-page>`. Set the `NXF_SYNTAX_PARSER` environment variable to `v2` to enable:

```bash
export NXF_SYNTAX_PARSER=v2
```
:::

Static typing is a new way to write Nextflow pipelines using *type annotations*. Type annotations help document and validate pipeline code.

```nextflow
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 {ref}`standard types <stdlib-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:

```nextflow
// 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`:

```nextflow
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 {ref}`dataflow-page` for more information.

Groovy-style type annotations (e.g., `String x`) are still supported for functions and local variables. However, the language server and `nextflow lint` will automatically convert them to Nextflow-style annotations during code formatting.

:::{warning}
Since Nextflow-style type annotations are new in Nextflow 25.10, formatting code with Groovy-style type annotations will make it incompatible with previous versions of Nextflow. If you need your code to remain compatible with versions prior to 25.10, run the formatter with Nextflow 25.04:

```bash
NXF_VER=25.04.8 nextflow lint -format .
```
:::

See {ref}`migrating-static-types` for details.

<h3>Auth and Launch commands</h3>

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.

```bash
# 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 {ref}`cli-auth` and {ref}`cli-launch` for details.

## Enhancements

<h3>Nextflow plugin registry</h3>

Nextflow now uses the [Nextflow plugin registry](https://registry.nextflow.io/) 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:

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

:::{note}
Plugins should be updated to publish to the Nextflow plugin registry using the {ref}`Nextflow Gradle plugin <gradle-plugin-page>` instead of the legacy plugin index. See {ref}`plugin-registry-page` for details.
:::

<h3>New syntax for workflow handlers</h3>

:::{note}
The new syntax for workflow handlers require the {ref}`strict syntax <strict-syntax-page>`. Set the `NXF_SYNTAX_PARSER` environment variable to `v2` to enable:

```bash
export NXF_SYNTAX_PARSER=v2
```
:::

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:

```nextflow
workflow {
    main:
    // ...

    onComplete:
    println "workflow complete"

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

This syntax is simpler and easier to use with the {ref}`strict syntax <strict-syntax-page>`. See {ref}`workflow-handlers` for details.

<h3>Simpler syntax for dynamic directives</h3>

The {ref}`strict syntax <strict-syntax-page>` allows dynamic process directives to be specified without a closure:

```nextflow
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 {ref}`dynamic-directives` for details.

<h3>Configurable date formatting</h3>

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

```bash
# 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 {ref}`the guide <aws-java-sdk-v2-page>` for details.

- The `nextflow.config.schema` package was renamed to `nextflow.config.spec`. Plugin developers that define custom {ref}`configuration scopes <dev-plugins-extension-points-config>` 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`). {ref}`Legacy parameters <workflow-params-legacy>` 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 {ref}`config-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 {ref}`strict syntax <strict-syntax-page>` 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