Configuration

Configuration file

When a pipeline script is launched, Nextflow looks for configuration files in multiple locations. Since each configuration file can contain conflicting settings, the sources are ranked to determine which settings are applied. Possible configuration sources, in order of priority:

Parameters specified on the command line (--something value)
Parameters provided using the -params-file option
Config file specified using the -c my_config option
The config file named nextflow.config in the current directory
The config file named nextflow.config in the workflow project directory
The config file $HOME/.nextflow/config
Values defined within the pipeline script itself (e.g. main.nf)

When more than one of these options for specifying configurations are used, they are merged, so that the settings in the first override the same settings appearing in the second, and so on.

Tip

If you want to ignore any default configuration files and use only a custom one, use -C <config file>.

Config syntax

A Nextflow configuration file is a simple text file containing a set of properties defined using the syntax:

name = value

Please note, string values need to be wrapped in quotation characters while numbers and boolean values (true, false) do not. Also note that values are typed. This means that, for example, 1 is different from '1' — the former is interpreted as the number one, while the latter is interpreted as a string value.

Config variables

Configuration properties can be used as variables in the configuration file by using the usual $propertyName or ${expression} syntax.

For example:

propertyOne = 'world'
anotherProp = "Hello $propertyOne"
customPath = "$PATH:/my/app/folder"

Please note, the usual rules for String interpolation are applied, thus a string containing a variable reference must be wrapped in double-quote chars instead of single-quote chars.

The same mechanism allows you to access environment variables defined in the hosting system. Any variable name not defined in the Nextflow configuration file(s) is interpreted to be a reference to an environment variable with that name. So, in the above example, the property customPath is defined as the current system PATH to which the string /my/app/folder is appended.

Config comments

Configuration files use the same conventions for comments used by the Groovy or Java programming languages. Thus, use // to comment a single line, or /* .. */ to comment a block on multiple lines.

Config include

A configuration file can include one or more configuration files using the keyword includeConfig. For example:

process.executor = 'sge'
process.queue = 'long'
process.memory = '10G'

includeConfig 'path/foo.config'

When a relative path is used, it is resolved against the actual location of the including file.

Config scopes

Configuration settings can be organized in different scopes by dot prefixing the property names with a scope identifier, or grouping the properties in the same scope using the curly brackets notation. For example:

alpha.x = 1
alpha.y = 'string value..'

beta {
     p = 2
     q = 'another string ..'
}

Scope `apptainer`

The apptainer scope controls how Apptainer containers are executed by Nextflow.

The following settings are available:

apptainer.autoMounts: When true Nextflow automatically mounts host paths in the executed container. It requires the user bind control feature to be enabled in your Apptainer installation (default: false).
apptainer.cacheDir: The directory where remote Apptainer images are stored. When using a computing cluster it must be a shared folder accessible to all compute nodes.
apptainer.enabled: Enable Apptainer execution (default: false).
apptainer.engineOptions: This attribute can be used to provide any option supported by the Apptainer engine i.e. apptainer [OPTIONS].
apptainer.envWhitelist: Comma separated list of environment variable names to be included in the container environment.
apptainer.noHttps: Pull the Apptainer image with http protocol (default: false).
apptainer.pullTimeout: The amount of time the Apptainer pull can last, exceeding which the process is terminated (default: 20 min).
apptainer.registry: The registry from where Docker images are pulled. It should be only used to specify a private registry server. It should NOT include the protocol prefix i.e. http://.
apptainer.runOptions: This attribute can be used to provide any extra command line options supported by apptainer exec.

Read the Apptainer page to learn more about how to use Apptainer containers with Nextflow.

Scope `aws`

The aws scope controls the interactions with AWS, including AWS Batch and S3. For example:

aws {
    accessKey = '<YOUR S3 ACCESS KEY>'
    secretKey = '<YOUR S3 SECRET KEY>'
    region = 'us-east-1'

    client {
        maxConnections = 20
        connectionTimeout = 10000
        uploadStorageClass = 'INTELLIGENT_TIERING'
        storageEncryption = 'AES256'
    }
    batch {
        cliPath = '/home/ec2-user/miniconda/bin/aws'
        maxTransferAttempts = 3
        delayBetweenAttempts = '5 sec'
    }
}

Tip

This scope can also be used to configure access to S3-compatible storage outside of AWS, such as Ceph and MinIO.

Read the Amazon Web Services and Amazon S3 storage pages for more information.

The following settings are available:

aws.accessKey: AWS account access key
aws.profile: New in version 22.12.0-edge.; AWS profile from ~/.aws/credentials
aws.region: AWS region (e.g. us-east-1)
aws.secretKey: AWS account secret key
aws.batch.cliPath: The path where the AWS command line tool is installed in the host AMI.
aws.batch.delayBetweenAttempts: Delay between download attempts from S3 (default: 10 sec).
aws.batch.jobRole: The AWS Job Role ARN that needs to be used to execute the Batch Job.
aws.batch.logsGroup: New in version 22.09.0-edge.; The name of the logs group used by Batch Jobs (default: /aws/batch).
aws.batch.maxParallelTransfers: Max parallel upload/download transfer operations per job (default: 4).
aws.batch.maxSpotAttempts: New in version 22.04.0.; Max number of execution attempts of a job interrupted by a EC2 spot reclaim event (default: 5)
aws.batch.maxTransferAttempts: Max number of downloads attempts from S3 (default: 1).
aws.batch.retryMode: The retry mode configuration setting, to accommodate rate-limiting on AWS services (default: standard, other options: legacy, adaptive); this handling is delegated to AWS. To have Nextflow handle retries instead, use built-in.
aws.batch.schedulingPriority: New in version 23.01.0-edge.; The scheduling priority for all tasks when using fair-share scheduling for AWS Batch (default: 0)
aws.batch.shareIdentifier: New in version 22.09.0-edge.; The share identifier for all tasks when using fair-share scheduling for AWS Batch
aws.batch.volumes: One or more container mounts. Mounts can be specified as simple e.g. /some/path or canonical format e.g. /host/path:/mount/path[:ro|rw]. Multiple mounts can be specified separating them with a comma or using a list object.
aws.client.anonymous: Allow the access of public S3 buckets without the need to provide AWS credentials. Any service that does not accept unsigned requests will return a service access error.
aws.client.s3Acl: Allow the setting of predefined bucket permissions, also known as canned ACL. Permitted values are Private, PublicRead, PublicReadWrite, AuthenticatedRead, LogDeliveryWrite, BucketOwnerRead, BucketOwnerFullControl, and AwsExecRead. See Amazon docs for details.
aws.client.connectionTimeout: The amount of time to wait (in milliseconds) when initially establishing a connection before timing out.
aws.client.endpoint: The AWS S3 API entry point e.g. s3-us-west-1.amazonaws.com.
aws.client.glacierAutoRetrieval: New in version 22.12.0-edge.; Experimental: may change in a future release.; Enable auto retrieval of S3 objects stored with Glacier class store (default: false).
aws.client.glacierExpirationDays: New in version 22.12.0-edge.; Experimental: may change in a future release.; The time, in days, between when an object is restored to the bucket and when it expires (default: 7).
aws.client.glacierRetrievalTier: New in version 23.03.0-edge.; Experimental: may change in a future release.; The retrieval tier to use when restoring objects from Glacier, one of [Expedited, Standard, Bulk].
aws.client.maxConnections: The maximum number of allowed open HTTP connections.
aws.client.maxErrorRetry: The maximum number of retry attempts for failed retryable requests.
aws.client.protocol: The protocol (i.e. HTTP or HTTPS) to use when connecting to AWS.
aws.client.proxyHost: The proxy host to connect through.
aws.client.proxyPort: The port on the proxy host to connect through.
aws.client.proxyUsername: The user name to use when connecting through a proxy.
aws.client.proxyPassword: The password to use when connecting through a proxy.
aws.client.s3PathStyleAccess: Enable the use of path-based access model that is used to specify the address of an object in S3-compatible storage systems.
aws.client.signerOverride: The name of the signature algorithm to use for signing requests made by the client.
aws.client.socketSendBufferSizeHint: The Size hint (in bytes) for the low level TCP send buffer.
aws.client.socketRecvBufferSizeHint: The Size hint (in bytes) for the low level TCP receive buffer.
aws.client.socketTimeout: The amount of time to wait (in milliseconds) for data to be transferred over an established, open connection before the connection is timed out.
aws.client.storageEncryption: The S3 server side encryption to be used when saving objects on S3, either AES256 or aws:kms values are allowed.
aws.client.storageKmsKeyId: New in version 22.05.0-edge.; The AWS KMS key Id to be used to encrypt files stored in the target S3 bucket ().
aws.client.userAgent: The HTTP user agent header passed with all HTTP requests.
aws.client.uploadChunkSize: The size of a single part in a multipart upload (default: 100 MB).
aws.client.uploadMaxAttempts: The maximum number of upload attempts after which a multipart upload returns an error (default: 5).
aws.client.uploadMaxThreads: The maximum number of threads used for multipart upload.
aws.client.uploadRetrySleep: The time to wait after a failed upload attempt to retry the part upload (default: 500ms).
aws.client.uploadStorageClass: The S3 storage class applied to stored objects, one of [STANDARD, STANDARD_IA, ONEZONE_IA, INTELLIGENT_TIERING] (default: STANDARD).

Scope `azure`

The azure scope allows you to configure the interactions with Azure, including Azure Batch and Azure Blob Storage.

Read the Azure Cloud page for more information.

The following settings are available:

azure.activeDirectory.servicePrincipalId: The service principal client ID
azure.activeDirectory.servicePrincipalSecret: The service principal client secret
azure.activeDirectory.tenantId: The Azure tenant ID
azure.batch.accountName: The batch service account name.
azure.batch.accountKey: The batch service account key.
azure.batch.allowPoolCreation: Enable the automatic creation of batch pools specified in the Nextflow configuration file (default: false).
azure.batch.autoPoolMode: Enable the automatic creation of batch pools depending on the pipeline resources demand (default: true).
azure.batch.copyToolInstallMode: Specify where the azcopy tool used by Nextflow. When node is specified it’s copied once during the pool creation. When task is provider, it’s installed for each task execution (default: node).
azure.batch.deleteJobsOnCompletion: Delete all jobs when the workflow completes (default: false).; Changed in version 23.08.0-edge: Default value was changed from true to false.
azure.batch.deletePoolsOnCompletion: Delete all compute node pools when the workflow completes (default: false).
azure.batch.deleteTasksOnCompletion: New in version 23.08.0-edge.; Delete each task when it completes (default: true).; Although this setting is enabled by default, failed tasks will not be deleted unless it is explicitly enabled. This way, the default behavior is that successful tasks are deleted while failed tasks are preserved for debugging purposes.
azure.batch.endpoint: The batch service endpoint e.g. https://nfbatch1.westeurope.batch.azure.com.
azure.batch.location: The name of the batch service region, e.g. westeurope or eastus2. This is not needed when the endpoint is specified.
azure.batch.terminateJobsOnCompletion: New in version 23.05.0-edge.; When the workflow completes, set all jobs to terminate on task completion. (default: true).
azure.batch.pools.<name>.autoScale: Enable autoscaling feature for the pool identified with <name>.
azure.batch.pools.<name>.fileShareRootPath: New in nf-azure version 0.11.0; If mounting File Shares, this is the internal root mounting point. Must be /mnt/resource/batch/tasks/fsmounts for CentOS nodes or /mnt/batch/tasks/fsmounts for Ubuntu nodes (default is for CentOS).
azure.batch.pools.<name>.maxVmCount: Specify the max of virtual machine when using auto scale option.
azure.batch.pools.<name>.mountOptions: New in nf-azure version 0.11.0; Specify the mount options for mounting the file shares (default: -o vers=3.0,dir_mode=0777,file_mode=0777,sec=ntlmssp).
azure.batch.pools.<name>.offer: New in nf-azure version 0.11.0; Specify the offer type of the virtual machine type used by the pool identified with <name> (default: centos-container).
azure.batch.pools.<name>.privileged: Enable the task to run with elevated access. Ignored if runAs is set (default: false).
azure.batch.pools.<name>.publisher: New in nf-azure version 0.11.0; Specify the publisher of virtual machine type used by the pool identified with <name> (default: microsoft-azure-batch).
azure.batch.pools.<name>.runAs: Specify the username under which the task is run. The user must already exist on each node of the pool.
azure.batch.pools.<name>.scaleFormula: Specify the scale formula for the pool identified with <name>. See Azure Batch scaling documentation for details.
azure.batch.pools.<name>.scaleInterval: Specify the interval at which to automatically adjust the Pool size according to the autoscale formula. The minimum and maximum value are 5 minutes and 168 hours respectively (default: 10 mins).
azure.batch.pools.<name>.schedulePolicy: Specify the scheduling policy for the pool identified with <name>. It can be either spread or pack (default: spread).
azure.batch.pools.<name>.sku: New in nf-azure version 0.11.0; Specify the ID of the Compute Node agent SKU which the pool identified with <name> supports (default: batch.node.centos 8).
azure.batch.pools.<name>.virtualNetwork: New in version 23.03.0-edge.; Specify the subnet ID of a virtual network in which to create the pool.
azure.batch.pools.<name>.vmCount: Specify the number of virtual machines provisioned by the pool identified with <name>.
azure.batch.pools.<name>.vmType: Specify the virtual machine type used by the pool identified with <name>.
azure.registry.server: New in nf-azure version 0.9.8; Specify the container registry from which to pull the Docker images (default: docker.io).
azure.registry.userName: New in nf-azure version 0.9.8; Specify the username to connect to a private container registry.
azure.registry.password: New in nf-azure version 0.9.8; Specify the password to connect to a private container registry.
azure.retryPolicy.delay: Delay when retrying failed API requests (default: 500ms).
azure.retryPolicy.jitter: Jitter value when retrying failed API requests (default: 0.25).
azure.retryPolicy.maxAttempts: Max attempts when retrying failed API requests (default: 10).
azure.retryPolicy.maxDelay: Max delay when retrying failed API requests (default: 90s).
azure.storage.accountName: The blob storage account name
azure.storage.accountKey: The blob storage account key
azure.storage.sasToken: The blob storage shared access signature token. This can be provided as an alternative to the accountKey setting.
azure.storage.tokenDuration: The duration of the shared access signature token created by Nextflow when the sasToken option is not specified (default: 48h).

Scope `charliecloud`

The charliecloud scope controls how Charliecloud containers are executed by Nextflow.

The following settings are available:

charliecloud.cacheDir: The directory where remote Charliecloud images are stored. When using a computing cluster it must be a shared folder accessible to all compute nodes.
charliecloud.enabled: Enable Charliecloud execution (default: false).
charliecloud.envWhitelist: Comma separated list of environment variable names to be included in the container environment.
charliecloud.pullTimeout: The amount of time the Charliecloud pull can last, exceeding which the process is terminated (default: 20 min).
charliecloud.runOptions: This attribute can be used to provide any extra command line options supported by the ch-run command.
charliecloud.temp: Mounts a path of your choice as the /tmp directory in the container. Use the special value auto to create a temporary directory each time a container is created.

Read the Charliecloud page to learn more about how to use Charliecloud containers with Nextflow.

Scope `conda`

The conda scope controls the creation of a Conda environment by the Conda package manager.

The following settings are available:

conda.enabled: Enable Conda execution (default: false).
conda.cacheDir: Defines the path where Conda environments are stored. When using a compute cluster make sure to provide a shared file system path accessible from all compute nodes.
conda.createOptions: Defines any extra command line options supported by the conda create command. For details see the Conda documentation.
conda.createTimeout: Defines the amount of time the Conda environment creation can last. The creation process is terminated when the timeout is exceeded (default: 20 min).
conda.useMamba: Uses the mamba binary instead of conda to create the Conda environments. For details see the Mamba documentation.
conda.useMicromamba: New in version 22.05.0-edge.; uses the micromamba binary instead of conda to create the Conda environments. For details see the Micromamba documentation.

Read the Conda environments page to learn more about how to use Conda environments with Nextflow.

Scope `dag`

The dag scope controls the workflow diagram generated by Nextflow.

The following settings are available:

dag.enabled: When true enables the generation of the DAG file (default: false).
dag.depth: New in version 23.10.0.; Only supported by the HTML and Mermaid renderers.; Controls the maximum depth at which to render sub-workflows (default: no limit).
dag.direction: New in version 23.10.0.
:::: Only supported by the HTML and Mermaid renderers.; Controls the direction of the DAG, can be 'LR' (left-to-right) or 'TB' (top-to-bottom) (default: 'TB').
dag.file: Graph file name (default: dag-<timestamp>.html).
dag.overwrite: When true overwrites any existing DAG file with the same name (default: false).
dag.verbose: New in version 23.10.0.; Only supported by the HTML and Mermaid renderers.; When false, channel names are omitted, operators are collapsed, and empty workflow inputs are removed (default: false).

Read the DAG visualisation page to learn more about the workflow graph that can be generated by Nextflow.

Scope `docker`

The docker scope controls how Docker containers are executed by Nextflow.

The following settings are available:

docker.enabled: Enable Docker execution (default: false).
docker.engineOptions: This attribute can be used to provide any option supported by the Docker engine i.e. docker [OPTIONS].
docker.envWhitelist: Comma separated list of environment variable names to be included in the container environment.
docker.fixOwnership: Fix ownership of files created by the docker container.
docker.legacy: Use command line options removed since Docker 1.10.0 (default: false).
docker.mountFlags: Add the specified flags to the volume mounts e.g. mountFlags = 'ro,Z'.
docker.registry: The registry from where Docker images are pulled. It should be only used to specify a private registry server. It should NOT include the protocol prefix i.e. http://.
docker.remove: Clean-up the container after the execution (default: true). See the Docker documentation for details.
docker.runOptions: This attribute can be used to provide any extra command line options supported by the docker run command. See the Docker documentation for details.
docker.sudo: Executes Docker run command as sudo (default: false).
docker.temp: Mounts a path of your choice as the /tmp directory in the container. Use the special value auto to create a temporary directory each time a container is created.
docker.tty: Allocates a pseudo-tty (default: false).

Read the Docker page to learn more about how to use Docker containers with Nextflow.

Scope `env`

The env scope allows the definition one or more variables that will be exported into the environment where workflow tasks are executed.

Simply prefix your variable names with the env scope or surround them by curly brackets, as shown below:

env.ALPHA = 'some value'
env.BETA = "$HOME/some/path"

env {
     DELTA = 'one more'
     GAMMA = "/my/path:$PATH"
}

Note

In the above example, variables like $HOME and $PATH are evaluated when the workflow is launched. If you want these variables to be evaluated during task execution, escape them with \$. This difference is important for variables like $PATH, which may be different in the workflow environment versus the task environment.

Warning

The env scope provides environment variables to tasks, not Nextflow itself. Nextflow environment variables such as NXF_VER should be set in the environment in which Nextflow is launched.

Scope `executor`

The executor scope controls various executor behaviors.

The following settings are available:

executor.cpus: The maximum number of CPUs made available by the underlying system. Used only by the local executor.
executor.dumpInterval: Determines how often to log the executor status (default: 5min).
executor.exitReadTimeout: Determines how long to wait before returning an error status when a process is terminated but the .exitcode file does not exist or is empty (default: 270 sec). Used only by grid executors.
executor.jobName: Determines the name of jobs submitted to the underlying cluster executor e.g. executor.jobName = { "$task.name - $task.hash" }. Make sure the resulting job name matches the validation constraints of the underlying batch scheduler.
executor.killBatchSize: Determines the number of jobs that can be killed in a single command execution (default: 100).
executor.memory: The maximum amount of memory made available by the underlying system. Used only by the local executor.
executor.name: The name of the executor to be used (default: local).
executor.perCpuMemAllocation: New in version 23.07.0-edge.; Used only by the SLURM executor.; When true, specifies memory allocations for SLURM jobs as --mem-per-cpu <task.memory / task.cpus> instead of --mem <task.memory>.
executor.perJobMemLimit: Specifies Platform LSF per-job memory limit mode. See LSF.
executor.perTaskReserve: Specifies Platform LSF per-task memory reserve mode. See LSF.
executor.pollInterval: Determines how often to check for process termination. Default varies for each executor (see below).
executor.queueGlobalStatus: New in version 23.01.0-edge.; Determines how job status is retrieved. When false only the queue associated with the job execution is queried. When true the job status is queried globally i.e. irrespective of the submission queue (default: false).
executor.queueSize: The number of tasks the executor will handle in a parallel manner. A queue size of zero corresponds to no limit. Default varies for each executor (see below).
executor.queueStatInterval: Determines how often to fetch the queue status from the scheduler (default: 1min). Used only by grid executors.
executor.retry.delay: New in version 22.03.0-edge.; Delay when retrying failed job submissions (default: 500ms). Used only by grid executors.
executor.retry.jitter: New in version 22.03.0-edge.; Jitter value when retrying failed job submissions (default: 0.25). Used only by grid executors.
executor.retry.maxAttempt: New in version 22.03.0-edge.; Max attempts when retrying failed job submissions (default: 3). Used only by grid executors.
executor.retry.maxDelay: New in version 22.03.0-edge.; Max delay when retrying failed job submissions (default: 30s). Used only by grid executors.
executor.retry.reason: New in version 22.03.0-edge.; Regex pattern that when verified cause a failed submit operation to be re-tried (default: Socket timed out). Used only by grid executors.
executor.submitRateLimit: Determines the max rate of job submission per time unit, for example '10sec' (10 jobs per second) or '50/2min' (50 jobs every 2 minutes) (default: unlimited).

Some executor settings have different default values depending on the executor.

Executor	`queueSize`	`pollInterval`
AWS Batch	`1000`	`10s`
Azure Batch	`1000`	`10s`
Google Batch	`1000`	`10s`
Grid Executors	`100`	`5s`
Kubernetes	`100`	`5s`
Local	N/A	`100ms`

The executor settings can be defined as shown below:

executor {
    name = 'sge'
    queueSize = 200
    pollInterval = '30 sec'
}

When using two (or more) different executors in your pipeline, you can specify their settings separately by prefixing the executor name with the symbol $ and using it as special scope identifier. For example:

executor {
  $sge {
      queueSize = 100
      pollInterval = '30sec'
  }

  $local {
      cpus = 8
      memory = '32 GB'
  }
}

The above configuration example can be rewritten using the dot notation as shown below:

executor.$sge.queueSize = 100
executor.$sge.pollInterval = '30sec'
executor.$local.cpus = 8
executor.$local.memory = '32 GB'

Scope `google`

The google scope allows you to configure the interactions with Google Cloud, including Google Cloud Batch, Google Life Sciences, and Google Cloud Storage.

Read the Google Cloud page for more information.

The following settings are available:

google.enableRequesterPaysBuckets: When true uses the given Google Cloud project ID as the billing project for storage access. This is required when accessing data from requester pays enabled buckets. See Requester Pays on Google Cloud Storage documentation (default: false).
google.httpConnectTimeout: New in version 23.06.0-edge.; Defines the HTTP connection timeout for Cloud Storage API requests (default: '60s').
google.httpReadTimeout: New in version 23.06.0-edge.; Defines the HTTP read timeout for Cloud Storage API requests (default: '60s').
google.location: The Google Cloud location where jobs are executed (default: us-central1).
google.project: The Google Cloud project ID to use for pipeline execution
google.region: Available only for Google Life Sciences; The Google Cloud region where jobs are executed. Multiple regions can be provided as a comma-separated list. Cannot be used with the google.zone option. See the Google Cloud documentation for a list of available regions and zones.
google.zone: Available only for Google Life Sciences; The Google Cloud zone where jobs are executed. Multiple zones can be provided as a comma-separated list. Cannot be used with the google.region option. See the Google Cloud documentation for a list of available regions and zones.
google.batch.allowedLocations: New in version 22.12.0-edge.; Define the set of allowed locations for VMs to be provisioned. See Google documentation for details (default: no restriction).
google.batch.bootDiskSize: Set the size of the virtual machine boot disk, e.g 50.GB (default: none).
google.batch.cpuPlatform: Set the minimum CPU Platform, e.g. 'Intel Skylake'. See Specifying a minimum CPU Platform for VM instances (default: none).
google.batch.network: Set network name to attach the VM’s network interface to. The value will be prefixed with global/networks/ unless it contains a /, in which case it is assumed to be a fully specified network resource URL. If unspecified, the global default network is used.
google.batch.serviceAccountEmail: Define the Google service account email to use for the pipeline execution. If not specified, the default Compute Engine service account for the project will be used.
google.batch.spot: When true enables the usage of spot virtual machines or false otherwise (default: false).
google.batch.subnetwork: Define the name of the subnetwork to attach the instance to must be specified here, when the specified network is configured for custom subnet creation. The value is prefixed with regions/subnetworks/ unless it contains a /, in which case it is assumed to be a fully specified subnetwork resource URL.
google.batch.usePrivateAddress: When true the VM will NOT be provided with a public IP address, and only contain an internal IP. If this option is enabled, the associated job can only load docker images from Google Container Registry, and the job executable cannot use external services other than Google APIs (default: false).
google.lifeSciences.bootDiskSize: Set the size of the virtual machine boot disk e.g 50.GB (default: none).
google.lifeSciences.copyImage: The container image run to copy input and output files. It must include the gsutil tool (default: google/cloud-sdk:alpine).
google.lifeSciences.cpuPlatform: Set the minimum CPU Platform e.g. 'Intel Skylake'. See Specifying a minimum CPU Platform for VM instances (default: none).
google.lifeSciences.debug: When true copies the /google debug directory in that task bucket directory (default: false).
google.lifeSciences.keepAliveOnFailure: New in version 21.06.0-edge.; When true and a task complete with an unexpected exit status the associated compute node is kept up for 1 hour. This options implies sshDaemon=true (default: false).
google.lifeSciences.network: New in version 21.03.0-edge.; Set network name to attach the VM’s network interface to. The value will be prefixed with global/networks/ unless it contains a /, in which case it is assumed to be a fully specified network resource URL. If unspecified, the global default network is used.
google.lifeSciences.preemptible: When true enables the usage of preemptible virtual machines or false otherwise (default: true).
google.lifeSciences.serviceAccountEmail: New in version 20.05.0-edge.; Define the Google service account email to use for the pipeline execution. If not specified, the default Compute Engine service account for the project will be used.
google.lifeSciences.subnetwork: New in version 21.03.0-edge.; Define the name of the subnetwork to attach the instance to must be specified here, when the specified network is configured for custom subnet creation. The value is prefixed with regions/subnetworks/ unless it contains a /, in which case it is assumed to be a fully specified subnetwork resource URL.
google.lifeSciences.sshDaemon: When true runs SSH daemon in the VM carrying out the job to which it’s possible to connect for debugging purposes (default: false).
google.lifeSciences.sshImage: The container image used to run the SSH daemon (default: gcr.io/cloud-genomics-pipelines/tools).
google.lifeSciences.usePrivateAddress: New in version 20.03.0-edge.; When true the VM will NOT be provided with a public IP address, and only contain an internal IP. If this option is enabled, the associated job can only load docker images from Google Container Registry, and the job executable cannot use external services other than Google APIs (default: false).
google.storage.delayBetweenAttempts: New in version 21.06.0-edge.; Delay between download attempts from Google Storage (default 10 sec).
google.storage.downloadMaxComponents: New in version 21.06.0-edge.; Defines the value for the option GSUtil:sliced_object_download_max_components used by gsutil for transfer input and output data (default: 8).
google.storage.maxParallelTransfers: New in version 21.06.0-edge.; Max parallel upload/download transfer operations per job (default: 4).
google.storage.maxTransferAttempts: New in version 21.06.0-edge.; Max number of downloads attempts from Google Storage (default: 1).
google.storage.parallelThreadCount: New in version 21.06.0-edge.; Defines the value for the option GSUtil:parallel_thread_count used by gsutil for transfer input and output data (default: 1).

Scope `k8s`

The k8s scope controls the deployment and execution of workflow applications in a Kubernetes cluster.

The following settings are available:

k8s.autoMountHostPaths: Automatically mounts host paths in the job pods. Only for development purpose when using a single node cluster (default: false).
k8s.computeResourceType: New in version 22.05.0-edge.; Define whether use Kubernetes Pod or Job resource type to carry out Nextflow tasks (default: Pod).
k8s.context: Defines the Kubernetes configuration context name to use.
k8s.fetchNodeName: New in version 22.05.0-edge.; If you trace the hostname, activate this option (default: false).
k8s.httpConnectTimeout: New in version 22.10.0.; Defines the Kubernetes client request HTTP connection timeout e.g. '60s'.
k8s.httpReadTimeout: New in version 22.10.0.; Defines the Kubernetes client request HTTP connection read timeout e.g. '60s'.
k8s.launchDir: Defines the path where the workflow is launched and the user data is stored. This must be a path in a shared K8s persistent volume (default: <volume-claim-mount-path>/<user-name>).
k8s.maxErrorRetry: New in version 22.09.6-edge.; Defines the Kubernetes API max request retries (default: 4).
k8s.namespace: Defines the Kubernetes namespace to use (default: default).
k8s.pod: Allows the definition of one or more pod configuration options such as environment variables, config maps, secrets, etc. It allows the same settings as the pod process directive.
k8s.projectDir: Defines the path where Nextflow projects are downloaded. This must be a path in a shared K8s persistent volume (default: <volume-claim-mount-path>/projects).
k8s.pullPolicy: Defines the strategy to be used to pull the container image e.g. pullPolicy: 'Always'.
k8s.runAsUser: Defines the user ID to be used to run the containers. Shortcut for the securityContext option.
k8s.securityContext: Defines the security context for all pods.
k8s.serviceAccount: Defines the Kubernetes service account name to use.
k8s.storageClaimName: The name of the persistent volume claim where store workflow result data.
k8s.storageMountPath: The path location used to mount the persistent volume claim (default: /workspace).
k8s.storageSubPath: The path in the persistent volume to be mounted (default: /).
k8s.workDir: Defines the path where the workflow temporary data is stored. This must be a path in a shared K8s persistent volume (default: <user-dir>/work).

See the Kubernetes page for more details.

Scope `mail`

The mail scope controls the mail server used to send email notifications.

The following settings are available:

mail.debug: When true enables Java Mail logging for debugging purpose.
mail.from: Default email sender address.
mail.smtp.host: Host name of the mail server.
mail.smtp.port: Port number of the mail server.
mail.smtp.user: User name to connect to the mail server.
mail.smtp.password: User password to connect to the mail server.
mail.smtp.proxy.host: Host name of an HTTP web proxy server that will be used for connections to the mail server.
mail.smtp.proxy.port: Port number for the HTTP web proxy server.
mail.smtp.*: Any SMTP configuration property supported by the Java Mail API, which Nextflow uses to send emails. See the table of available properties here.

For example, the following snippet shows how to configure Nextflow to send emails through the AWS Simple Email Service:

mail {
    smtp.host = 'email-smtp.us-east-1.amazonaws.com'
    smtp.port = 587
    smtp.user = '<Your AWS SES access key>'
    smtp.password = '<Your AWS SES secret key>'
    smtp.auth = true
    smtp.starttls.enable = true
    smtp.starttls.required = true
}

Note

Some versions of Java (e.g. Java 11 Corretto) do not default to TLS v1.2, and as a result may have issues with 3rd party integrations that enforce TLS v1.2 (e.g. Azure Active Directory OIDC). This problem can be addressed by setting the following config option:

mail {
    smtp.ssl.protocols = 'TLSv1.2'
}

Scope `manifest`

The manifest scope allows you to define some meta-data information needed when publishing or running your pipeline.

The following settings are available:

manifest.author

Project author name (use a comma to separate multiple names).

manifest.defaultBranch

Git repository default branch (default: master).

manifest.description

Free text describing the workflow project.

manifest.doi

Project related publication DOI identifier.

manifest.homePage

Project home page URL.

manifest.mainScript

Project main script (default: main.nf).

manifest.name

Project short name.

manifest.nextflowVersion

Minimum required Nextflow version.

This setting may be useful to ensure that a specific version is used:

manifest.nextflowVersion = '1.2.3'        // exact match
manifest.nextflowVersion = '1.2+'         // 1.2 or later (excluding 2 and later)
manifest.nextflowVersion = '>=1.2'        // 1.2 or later
manifest.nextflowVersion = '>=1.2, <=1.5' // any version in the 1.2 .. 1.5 range
manifest.nextflowVersion = '!>=1.2'       // with ! prefix, stop execution if current version does not match required version.

manifest.recurseSubmodules

Pull submodules recursively from the Git repository.

manifest.version

Project version number.

The above options can also be specified in a manifest block, for example:

manifest {
    homePage = 'http://foo.com'
    description = 'Pipeline does this and that'
    mainScript = 'foo.nf'
    version = '1.0.0'
}

Read the Pipeline sharing page to learn how to publish your pipeline to GitHub, BitBucket or GitLab.

Scope `notification`

The notification scope allows you to define the automatic sending of a notification email message when the workflow execution terminates.

notification.binding: An associative array modelling the variables in the template file.
notification.enabled: Enables the sending of a notification message when the workflow execution completes.
notification.from: Sender address for the notification email message.
notification.template: Path of a template file which provides the content of the notification message.
notification.to: Recipient address for the notification email. Multiple addresses can be specified separating them with a comma.

The notification message is sent my using the STMP server defined in the configuration mail scope.

If no mail configuration is provided, it tries to send the notification message by using the external mail command eventually provided by the underlying system (e.g. sendmail or mail).

Scope `params`

The params scope allows you to define parameters that will be accessible in the pipeline script. Simply prefix the parameter names with the params scope or surround them by curly brackets, as shown below:

params.custom_param = 123
params.another_param = 'string value .. '

params {
    alpha_1 = true
    beta_2 = 'another string ..'
}

Scope `podman`

The podman scope controls how Podman containers are executed by Nextflow.

The following settings are available:

podman.enabled: Enable Podman execution (default: false).
podman.engineOptions: This attribute can be used to provide any option supported by the Podman engine i.e. podman [OPTIONS].
podman.envWhitelist: Comma separated list of environment variable names to be included in the container environment.
podman.mountFlags: Add the specified flags to the volume mounts e.g. mountFlags = 'ro,Z'.
podman.registry: The registry from where container images are pulled. It should be only used to specify a private registry server. It should NOT include the protocol prefix i.e. http://.
podman.remove: Clean-up the container after the execution (default: true).
podman.runOptions: This attribute can be used to provide any extra command line options supported by the podman run command.
podman.temp: Mounts a path of your choice as the /tmp directory in the container. Use the special value auto to create a temporary directory each time a container is created.

Read the Podman page to learn more about how to use Podman containers with Nextflow.

Scope `process`

The process scope allows you to specify default directives for processes in your pipeline.

For example:

process {
    executor = 'sge'
    queue = 'long'
    clusterOptions = '-pe smp 10 -l virtual_free=64G,h_rt=30:00:00'
}

By using this configuration, all processes in your pipeline will be executed through the SGE cluster, with the specified settings.

Process selectors

The withLabel selectors allow the configuration of all processes annotated with a label directive as shown below:

process {
    withLabel: big_mem {
        cpus = 16
        memory = 64.GB
        queue = 'long'
    }
}

The above configuration example assigns 16 cpus, 64 Gb of memory and the long queue to all processes annotated with the big_mem label.

In the same manner, the withName selector allows the configuration of a specific process in your pipeline by its name. For example:

process {
    withName: hello {
        cpus = 4
        memory = 8.GB
        queue = 'short'
    }
}

Note

The withName selector applies to a process even when it is included from a module under an alias. For example, withName: hello will apply to any process originally defined as hello, regardless of whether it is included under an alias. Similarly, it will not apply to any process not originally defined as hello, even if it is included under the alias hello.

Tip

Label and process names do not need to be enclosed with quotes, provided the name does not include special characters (-, !, etc) and is not a keyword or a built-in type identifier. When in doubt, you can enclose the label name or process name with single or double quotes.

Selector expressions

Both label and process name selectors allow the use of a regular expression in order to apply the same configuration to all processes matching the specified pattern condition. For example:

process {
    withLabel: 'foo|bar' {
        cpus = 2
        memory = 4.GB
    }
}

The above configuration snippet sets 2 cpus and 4 GB of memory to the processes annotated with a label foo and bar.

A process selector can be negated prefixing it with the special character !. For example:

process {
    withLabel: 'foo' { cpus = 2 }
    withLabel: '!foo' { cpus = 4 }
    withName: '!align.*' { queue = 'long' }
}

The above configuration snippet sets 2 cpus for the processes annotated with the foo label and 4 cpus to all processes not annotated with that label. Finally it sets the use of long queue to all process whose name does not start with align.

Selector priority

When mixing generic process configuration and selectors the following priority rules are applied (from lower to higher):

Process generic configuration.
Process specific directive defined in the workflow script.
withLabel selector definition.
withName selector definition.

For example:

process {
    cpus = 4
    withLabel: foo { cpus = 8 }
    withName: bar { cpus = 32 }
}

Using the above configuration snippet, all workflow processes use 4 cpus if not otherwise specified in the workflow script. Moreover processes annotated with the foo label use 8 cpus. Finally the process named bar uses 32 cpus.

Scope `report`

The report scope allows you to configure the workflow Execution report.

The following settings are available:

report.enabled: If true it create the workflow execution report.
report.file: The path of the created execution report file (default: report-<timestamp>.html).
report.overwrite: When true overwrites any existing report file with the same name.

Scope `sarus`

The sarus scope controls how Sarus containers are executed by Nextflow.

The following settings are available:

sarus.enabled: Enable Sarus execution (default: false).
sarus.envWhitelist: Comma separated list of environment variable names to be included in the container environment.
sarus.runOptions: This attribute can be used to provide any extra command line options supported by the sarus run command. For details see the Sarus user guide.
sarus.tty: Allocates a pseudo-tty (default: false).

Read the Sarus page to learn more about how to use Sarus containers with Nextflow.

Scope `shifter`

The shifter scope controls how Shifter containers are executed by Nextflow.

The following settings are available:

shifter.enabled: Enable Shifter execution (default: false).

Read the Shifter page to learn more about how to use Shifter containers with Nextflow.

Scope `singularity`

The singularity scope controls how Singularity containers are executed by Nextflow.

The following settings are available:

singularity.autoMounts: When true Nextflow automatically mounts host paths in the executed container. It requires the user bind control feature to be enabled in your Singularity installation (default: true).; Changed in version 23.09.0-edge: Default value was changed from false to true.
singularity.cacheDir: The directory where remote Singularity images are stored. When using a computing cluster it must be a shared folder accessible to all compute nodes.
singularity.enabled: Enable Singularity execution (default: false).
singularity.engineOptions: This attribute can be used to provide any option supported by the Singularity engine i.e. singularity [OPTIONS].
singularity.envWhitelist: Comma separated list of environment variable names to be included in the container environment.
singularity.noHttps: Pull the Singularity image with http protocol (default: false).
singularity.pullTimeout: The amount of time the Singularity pull can last, exceeding which the process is terminated (default: 20 min).
singularity.registry: New in version 22.12.0-edge.; The registry from where Docker images are pulled. It should be only used to specify a private registry server. It should NOT include the protocol prefix i.e. http://.
singularity.runOptions: This attribute can be used to provide any extra command line options supported by singularity exec.

Read the Singularity page to learn more about how to use Singularity containers with Nextflow.

Scope `spack`

The spack scope controls the creation of a Spack environment by the Spack package manager.

The following settings are available:

spack.cacheDir: Defines the path where Spack environments are stored. When using a compute cluster make sure to provide a shared file system path accessible from all compute nodes.
spack.checksum: Enables checksum verification for source tarballs (default: true). Only disable when requesting a package version not yet encoded in the corresponding Spack recipe.
spack.createTimeout: Defines the amount of time the Spack environment creation can last. The creation process is terminated when the timeout is exceeded (default: 60 min).
spack.parallelBuilds: Sets number of parallel package builds (Spack default: coincides with number of available CPU cores).

Nextflow does not allow for fine-grained configuration of the Spack package manager. Instead, this has to be performed directly on the host Spack installation. For more information see the Spack documentation.

Scope `timeline`

The timeline scope controls the execution timeline report generated by Nextflow.

The following settings are available:

timeline.enabled: When true enables the generation of the timeline report file (default: false).
timeline.file: Timeline file name (default: timeline-<timestamp>.html).
timeline.overwrite: When true overwrites any existing timeline file with the same name.

Scope `tower`

The tower scope controls the settings for the Nextflow Tower monitoring and tracing service.

The following settings are available:

tower.accessToken

The unique access token specific to your account on an instance of Tower.

Your accessToken can be obtained from your Tower instance in the Tokens page.

tower.enabled

When true Nextflow sends the workflow tracing and execution metrics to the Nextflow Tower service (default: false).

tower.endpoint

The endpoint of your Tower deployment (default: https://tower.nf).

tower.workspaceId

The ID of the Tower workspace where the run should be added (default: the launching user personal workspace).

The Tower workspace ID can also be specified using the environment variable TOWER_WORKSPACE_ID (config file has priority over the environment variable).

Scope `trace`

The trace scope controls the layout of the execution trace file generated by Nextflow.

The following settings are available:

trace.enabled: When true turns on the generation of the execution trace report file (default: false).
trace.fields: Comma separated list of fields to be included in the report. The available fields are listed at this page.
trace.file: Trace file name (default: trace-<timestamp>.txt).
trace.overwrite: When true overwrites any existing trace file with the same name.
trace.raw: When true turns on raw number report generation i.e. date and time are reported as milliseconds and memory as number of bytes.
trace.sep: Character used to separate values in each row (default: \t).

The above options can also be specified in a trace block, for example:

trace {
    enabled = true
    file = 'pipeline_trace.txt'
    fields = 'task_id,name,status,exit,realtime,%cpu,rss'
}

Read the Trace report page to learn more about the execution report that can be generated by Nextflow.

Miscellaneous

There are additional variables that can be defined within a configuration file that do not have a dedicated scope.

cleanup: If true, on a successful completion of a run all files in work directory are automatically deleted.

Warning

The use of the cleanup option will prevent the use of the resume feature on subsequent executions of that pipeline run. Also, be aware that deleting all scratch files can take a lot of time, especially when using a shared file system or remote cloud storage.
dumpHashes: If true, dump task hash keys in the log file, for debugging purposes.

Config profiles

Configuration files can contain the definition of one or more profiles. A profile is a set of configuration attributes that can be selected during pipeline execution by using the -profile command line option.

Configuration profiles are defined by using the special scope profiles, which group the attributes that belong to the same profile using a common prefix. For example:

profiles {

    standard {
        process.executor = 'local'
    }

    cluster {
        process.executor = 'sge'
        process.queue = 'long'
        process.memory = '10GB'
    }

    cloud {
        process.executor = 'cirrus'
        process.container = 'cbcrg/imagex'
        docker.enabled = true
    }

}

This configuration defines three different profiles: standard, cluster, and cloud, that each set different process configuration strategies depending on the target runtime platform. The standard profile is used by default when no profile is specified.

Tip

Multiple configuration profiles can be specified by separating the profile names with a comma, for example:

nextflow run <your script> -profile standard,cloud

Danger

When using the profiles feature in your config file, do NOT set attributes in the same scope both inside and outside a profiles context. For example:

process.cpus = 1

profiles {
  foo {
    process.memory = '2 GB'
  }

  bar {
    process.memory = '4 GB'
  }
}

In the above example, the process.cpus attribute is not correctly applied because the process scope is also used in the foo and bar profiles.

Environment variables

The following environment variables control the configuration of the Nextflow runtime and the underlying Java virtual machine.

NXF_ANSI_LOG: Enables/disables ANSI console output (default true when ANSI terminal is detected).
NXF_ANSI_SUMMARY: Enables/disables ANSI completion summary: true\|false (default: print summary if execution last more than 1 minute).
NXF_ASSETS: Defines the directory where downloaded pipeline repositories are stored (default: $NXF_HOME/assets)
NXF_CLOUDCACHE_PATH: New in version 23.07.0-edge.; Defines the base cache path when using the cloud cache store.
NXF_CHARLIECLOUD_CACHEDIR: Directory where remote Charliecloud images are stored. When using a computing cluster it must be a shared folder accessible from all compute nodes.
NXF_CLASSPATH: Allows the extension of the Java runtime classpath with extra JAR files or class folders.
NXF_CLOUD_DRIVER: Defines the default cloud driver to be used if not specified in the config file or as command line option, either aws or google.
NXF_CONDA_CACHEDIR: Directory where Conda environments are stored. When using a computing cluster it must be a shared folder accessible from all compute nodes.
NXF_CONDA_ENABLED: New in version 22.08.0-edge.; Enable the use of Conda recipes defined by using the conda directive. (default: false).
NXF_DEFAULT_DSL: New in version 22.03.0-edge.; Defines the DSL version that should be used in not specified otherwise in the script of config file (default: 2)
NXF_DISABLE_CHECK_LATEST: New in version 23.09.0-edge.; Nextflow automatically checks for a newer version of itself unless this option is enabled (default: false).
NXF_DISABLE_JOBS_CANCELLATION: New in version 21.12.0-edge.; Disables the cancellation of child jobs on workflow execution termination.
NXF_DISABLE_PARAMS_TYPE_DETECTION: New in version 23.07.0-edge.; Disables the automatic type detection of command line parameters.
NXF_DISABLE_WAVE_SERVICE: New in version 23.08.0-edge.; Disables the requirement for Wave service when enabling the Fusion file system.
NXF_ENABLE_AWS_SES: New in version 23.06.0-edge.; Enable to use of AWS SES native API for sending emails in place of legacy SMTP settings (default: false)
NXF_ENABLE_FS_SYNC: New in version 23.10.0.; When enabled the job script will execute Linux sync command on job completion. This may be useful to synchronize the job state over shared file systems (default: false)
NXF_ENABLE_SECRETS: New in version 21.09.0-edge.; Enable Nextflow secrets features (default: true)
NXF_ENABLE_STRICT: New in version 22.05.0-edge.; Enable Nextflow strict execution mode (default: false)
NXF_EXECUTOR: Defines the default process executor e.g. sge
NXF_FILE_ROOT: New in version 23.05.0-edge.; The file storage path against which relative file paths are resolved.; For example, with NXF_FILE_ROOT=/some/root/path, the use of file('foo') will be resolved to the absolute path /some/root/path/foo. A remote root path can be specified using the usual protocol prefix, e.g. NXF_FILE_ROOT=s3://my-bucket/data. Files defined using an absolute path are not affected by this setting.
NXF_HOME: Nextflow home directory (default: $HOME/.nextflow).
NXF_JAVA_HOME: Defines the path location of the Java VM installation used to run Nextflow. This variable overrides the JAVA_HOME variable if defined.
NXF_JVM_ARGS: New in version 21.12.1-edge.; Allows the setting Java VM options. This is similar to NXF_OPTS however it’s only applied the JVM running Nextflow and not to any java pre-launching commands.
NXF_OFFLINE: When true disables the project automatic download and update from remote repositories (default: false).; Changed in version 23.09.0-edge: This option also disables the automatic version check (see NXF_DISABLE_CHECK_LATEST).
NXF_OPTS: Provides extra options for the Java and Nextflow runtime. It must be a blank separated list of -Dkey[=value] properties.
NXF_ORG: Default organization prefix when looking for a hosted repository (default: nextflow-io).
NXF_PARAMS_FILE: New in version 20.10.0.; Defines the path location of the pipeline parameters file .
NXF_PID_FILE: Name of the file where the process PID is saved when Nextflow is launched in background.
NXF_PLUGINS_DEFAULT: Whether to use the default plugins when no plugins are specified in the Nextflow configuration (default: true).
NXF_PLUGINS_DIR: The path where the plugin archives are loaded and stored (default: $NXF_HOME/plugins).
NXF_PLUGINS_TEST_REPOSITORY: New in version 23.04.0.; Defines a custom plugin registry or plugin release URL for testing plugins outside of the main registry. See Testing plugins for more information.
NXF_SCM_FILE: New in version 20.10.0.; Defines the path location of the SCM config file .
NXF_SINGULARITY_CACHEDIR: Directory where remote Singularity images are stored. When using a computing cluster it must be a shared folder accessible from all compute nodes.
NXF_SINGULARITY_LIBRARYDIR: New in version 21.09.0-edge.; Directory where remote Singularity images are retrieved. It should be a directory accessible to all compute nodes.
NXF_SPACK_CACHEDIR: Directory where Spack environments are stored. When using a computing cluster it must be a shared folder accessible from all compute nodes.
NXF_SPACK_ENABLED: New in version 23.02.0-edge.; Enable the use of Spack recipes defined by using the spack directive. (default: false).
NXF_TEMP: Directory where temporary files are stored
NXF_VER: Defines which version of Nextflow to use.
NXF_WORK: Directory where working files are stored (usually your scratch directory)
NXF_WRAPPER_STAGE_FILE_THRESHOLD: New in version 23.05.0-edge.; Defines the minimum size of the .command.run staging script for it to be written to a separate .command.stage file (default: '1 MB').; This setting is useful for executors that impose a size limit on job scripts.
JAVA_HOME: Defines the path location of the Java VM installation used to run Nextflow.
JAVA_CMD: Defines the path location of the Java binary command used to launch Nextflow.
HTTP_PROXY: Defines the HTTP proxy server.; New in version 21.06.0-edge: Proxy authentication is supported by providing the credentials in the proxy URL, e.g. http://user:password@proxy-host.com:port.
HTTPS_PROXY: Defines the HTTPS proxy server.; New in version 21.06.0-edge: Proxy authentication is supported by providing the credentials in the proxy URL, e.g. https://user:password@proxy-host.com:port.
FTP_PROXY: New in version 21.06.0-edge.; Defines the FTP proxy server. Proxy authentication is supported by providing the credentials in the proxy URL, e.g. ftp://user:password@proxy-host.com:port.
NO_PROXY: Defines one or more host names that should not use the proxy server. Separate multiple names using a comma character.

Feature flags

Some features can be enabled using the nextflow.enable and nextflow.preview flags. These flags can be specified in the pipeline script or the configuration file, and they are generally used to introduce experimental or other opt-in features.

nextflow.enable.configProcessNamesValidation

When true, prints a warning for every withName: process selector that doesn’t match a process in the pipeline (default: true).

nextflow.enable.dsl

Defines the DSL version to use (1 or 2).

New in version 22.03.0-edge: DSL2 is the default DSL version.

New in version 22.12.0-edge: DSL1 is no longer supported.

nextflow.enable.moduleBinaries

When true, enables the use of modules with binary scripts. See Module binaries for more information.

nextflow.enable.strict

New in version 22.05.0-edge.

When true, the pipeline is executed in “strict” mode, which introduces the following rules:

When reading a params file, Nextflow will fail if a dynamic param value references an undefined variable
When merging params from a config file with params from the command line, Nextflow will fail if a param is specified from both sources but with different types
When using the join operator, the failOnDuplicate option is true regardless of any user setting
When using the join operator, the failOnMismatch option is true (unless remainder is also true) regardless of any user setting
When using the publishDir process directive, the failOnError option is true regardless of any user setting
In a process definition, Nextflow will fail if an input or output tuple has only one element
In a process definition, Nextflow will fail if an output emit name is not a valid identifier (i.e. it should match the pattern /[A-Za-z_][A-Za-z0-9_]*/)
During a process execution, Nextflow will fail if a received input tuple does not have the same number of elements as was declared
During a process execution, Nextflow will fail if the storeDir directive is used with non-file outputs
Nextflow will fail if a pipeline param is referenced before it is defined
Nextflow will fail if multiple functions and/or processes with the same name are defined in a module script

nextflow.preview.recursion

New in version 21.11.0-edge.

Experimental: may change in a future release.

When true, enables process and workflow recursion. See this GitHub discussion for more information.

Configuration

Configuration file

Config syntax

Config variables

Config comments

Config include

Config scopes

Scope apptainer

Scope aws

Scope azure

Scope charliecloud

Scope conda

Scope dag

Scope docker

Scope env

Scope executor

Scope google

Scope k8s

Scope mail

Scope manifest

Scope notification

Scope params

Scope podman

Scope process

Process selectors

Selector expressions

Selector priority

Scope report

Scope sarus

Scope shifter

Scope singularity

Scope spack

Scope timeline

Scope tower

Scope trace

Miscellaneous

Config profiles

Environment variables

Feature flags

Scope `apptainer`

Scope `aws`

Scope `azure`

Scope `charliecloud`

Scope `conda`

Scope `dag`

Scope `docker`

Scope `env`

Scope `executor`

Scope `google`

Scope `k8s`

Scope `mail`

Scope `manifest`

Scope `notification`

Scope `params`

Scope `podman`

Scope `process`

Scope `report`

Scope `sarus`

Scope `shifter`

Scope `singularity`

Scope `spack`

Scope `timeline`

Scope `tower`

Scope `trace`