Seqera

Added in version 26.04

warning

Preview feature: may change in a future release.

The seqera executor runs pipeline tasks using Seqera Intelligent Compute. It submits each task to the Seqera scheduler service.

To enable this executor, set process.executor = 'seqera' in the nextflow.config file. Every pipeline process must specify a container image using the container directive. The pipeline work directory must be in an S3 bucket.

The executor requires Fusion (fusion.enabled = true). By default, Wave is also required, because it adds the Fusion client to the task containers.

Experimental: may change in a future release.

Set seqera.executor.fusionMode = 'native' to have the compute hosts provide the Fusion client instead. In this mode Wave is optional. When Wave is enabled, it works as usual, including the Fusion layer, which the compute hosts override with their own Fusion client. When Wave is disabled, tasks run with their container image as-is, and the project bin directory is not made available to them.

Use the following process directives to control resource requests and other job characteristics:

• accelerator
• arch
• container
• containerOptions
• cpus
• disk
• memory
• secret
• time

The following hints are supported:

• machineRequirement.capacityMode
• machineRequirement.diskAllocation
• machineRequirement.diskEncrypted
• machineRequirement.diskIops
• machineRequirement.diskMountPath
• machineRequirement.diskSize
• machineRequirement.diskThroughputMiBps
• machineRequirement.diskType
• machineRequirement.machineTypes
• machineRequirement.maxSpotAttempts
• machineRequirement.onDemandCostRatio
• machineRequirement.provisioning
• predictionModel

The machineRequirement.* hints override the corresponding field of the seqera.executor.machineRequirement config scope on a per-process basis. The predictionModel hint overrides the run-level seqera.executor.predictionModel for a single process. Set it to qr/v1 or qr/v2 to select a model, or to none to disable resource prediction for that process even when the run enables a model. When omitted, the process inherits the run-level prediction model. Use keys as-is, or with the seqera/ prefix to restrict them to this executor.

For example, to override the provisioning mode for a single process:

process hello {
    hints 'seqera/machineRequirement.provisioning': 'spotFirst'

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

To disable resource prediction for a single process when the run sets a model:

process hello {
    hints 'seqera/predictionModel': 'none'

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

To configure AWS credentials and S3 access for the work directory, see Amazon S3. See the seqera scope for the full config reference.

On-demand fallback cost limit

Added in version 26.10

With provisioning = 'spotFirst', the scheduler falls back to on-demand instances when spot capacity runs out, as long as on-demand stays within a cost limit. The limit is the maximum ratio of the highest on-demand hourly price to the highest spot price, across the instance types selected for a task. If the ratio exceeds the limit, the scheduler retries the task on spot instead. If spot capacity stays unavailable, the task fails with an error message that starts with on-demand fallback refused.

The scheduler applies a default limit for each cloud provider. To set a different limit for all tasks in the run, use onDemandCostRatio:

seqera {
    executor {
        machineRequirement {
            provisioning = 'spotFirst'
            onDemandCostRatio = 2.5    // fall back only while on-demand costs at most 2.5x spot
        }
    }
}

Leaving onDemandCostRatio unset is not the same as setting it to 0:

onDemandCostRatio	Behavior
Not set	The scheduler's default limit for the cloud provider applies.
0	No limit. Tasks always fall back to on-demand, regardless of price.
Greater than 0	The scheduler uses this value instead of its default limit.

Setting 0 does not disable the fallback. To disable it, set provisioning = 'spot'.

To override the limit for a single process, use a hint, as with provisioning. For example, to let a long-running process always fall back to on-demand:

process align {
    hints 'seqera/machineRequirement.onDemandCostRatio': 0

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

Tasks with different limits run on separate clusters. Tasks that set a limit, including 0, do not use the compute environment's warm pool.

GPUs

Use the accelerator directive to request GPUs. On AWS, Azure, and Google Cloud, the type option selects the GPU model. The scheduler only selects instance types with that GPU. For example:

process train {
    accelerator 1, type: 'nvidia-l4'

    script:
    """
    your_gpu_enabled --command --line
    """
}

The type option accepts:

• A GPU model ID, such as nvidia-t4, nvidia-l4, nvidia-a10g, nvidia-a100, nvidia-h100, or nvidia-h100-nvl.
• A Google Cloud accelerator name, such as nvidia-tesla-t4 or nvidia-h100-80gb.
• A short name, such as t4, l4, a100, or h100.
• A vendor, such as nvidia.com/gpu, to accept any GPU of that vendor.

Names are case-insensitive. The scheduler ignores any memory size in the name. For example, nvidia-a100-80gb selects any A100. The h100 name also selects H100 NVL instances. If you omit type, the scheduler selects any GPU instance type.

Only NVIDIA GPUs are supported. A task fails at submission if it requests an unknown GPU or a GPU from another vendor, such as amd.com/gpu. A task that requests a GPU the compute environment's region does not offer cannot be scheduled. Tasks that request different GPU models run on separate instances.

Available GPUs

Each cloud provider offers the following GPUs. Set type to the GPU model ID or the short name. Availability varies by region.

AWS

GPU model ID	Short name	Instance families
nvidia-t4	t4	g4dn
nvidia-a10g	a10g	g5
nvidia-l4	l4	g6, gr6
nvidia-l40s	l40s	g6e
nvidia-rtx-pro-4500	rtx-pro-4500	g7
nvidia-v100	v100	p3dn
nvidia-a100	a100	p4d
nvidia-h100	h100	p5
nvidia-b200	b200	p6-b200

Azure

GPU model ID	Short name	VM series
nvidia-m60	m60	NVv3
nvidia-t4	t4	NCasT4_v3
nvidia-v100	v100	NCv3, NDv2
nvidia-a10	a10	NCads_A10_v4, NVads_A10_v5
nvidia-a100	a100	NCads_A100_v4, NDasr_A100_v4, NDm_A100_v4
nvidia-h100	h100	ND_H100_v5
nvidia-h100-nvl	h100-nvl	NCads_H100_v5, NCCads_H100_v5
nvidia-h200	h200	ND_H200_v5
nvidia-rtx-pro-6000	rtx-pro-6000	NCds_RTXPRO6000BSE_v6

Google Cloud

GPU model ID	Short name	Machine series
nvidia-l4	l4	G2
nvidia-rtx-pro-6000	rtx-pro-6000	G4
nvidia-a100	a100	A2
nvidia-h100	h100	A3
nvidia-h200	h200	A3 Ultra
nvidia-b200	b200	A4

On Google Cloud, only machine series with built-in GPUs are available. GPUs attached to N1 machine types, such as the T4 and V100, are not supported.

Infrastructure failures

When a task fails because of the infrastructure rather than the task itself, for example when a Fusion Snapshot cannot be restored, the scheduler reports the failure as retryable. Nextflow then reruns the task in a new work directory, whatever the errorStrategy directive says.

Each rerun counts as one task failure towards the maxRetries directive (default: 1). The rerun keeps the same task.attempt, but if the task later fails and is retried by the errorStrategy directive, the reruns are included in the new task.attempt. Once the task has failed maxRetries times, an infrastructure failure is no longer rerun and is handled by the errorStrategy directive as usual.

To allow more reruns, increase maxRetries. For example:

process {
    maxRetries = 3
}

Disk support

When a process specifies the disk directive, the Seqera executor provisions storage for the task container. It supports two disk allocation strategies:

• task (default): Nextflow creates a dedicated EBS volume for each task at launch time. This provides isolated storage with configurable volume type, IOPS, throughput, and encryption.

• node: Uses the instance storage attached at the cluster level. Tasks running on the same node share this storage, which does not support EBS-specific options.

Task allocation (EBS volumes)

By default, Nextflow uses a gp3 volume with 325 MiB/s throughput, the recommended settings for Fusion. You can customize the EBS volume configuration:

seqera {
    executor {
        machineRequirement {
            diskAllocation = 'task'    // Per-task EBS volume (default)
            diskType = 'ebs/io1'       // Use provisioned IOPS SSD
            diskIops = 10000           // Required for io1/io2
            diskThroughputMiBps = 500  // Throughput for gp3 volumes
            diskEncrypted = true       // Enable KMS encryption
            diskMountPath = '/data'    // Container mount path (default: /tmp)
        }
    }
}

Supported volume types: ebs/gp3 (default), ebs/gp2, ebs/io1, ebs/io2, ebs/st1, ebs/sc1.

Node allocation (instance storage)

To use instance storage instead of per-task EBS volumes:

seqera {
    executor {
        machineRequirement {
            diskAllocation = 'node'    // Use instance storage
        }
    }
}

note

The EBS-specific options (diskType, diskIops, diskThroughputMiBps, diskEncrypted) do not apply to node allocation. Specifying them causes an error.