Sometimes you might want to break up a long WDL file into smaller components for easier maintenance. Sometimes you'll want to do it to reuse components in multiple workflows. Have no fear, imports are here! Imports allow you to reference other WDL files that contain entire workflows or even just raw tasks.

To import a WDL, you can use the import WDL construct at the top of your workflow:

import "<resource>" as <alias>

There are two types of resources that are supported in imports: http(s) and file-path based. Any public http(s) based URL can be used as the resource for an import, such as a website, github or a GA4GH compliant TES endpoint. For example:

import "http://mywdlrepository/my.wdl" as http_import1
import "" as http_import2

To use a file-based import resource, you must provide a ZIP bundle of your resources and then use a path relative to that ZIP in your import statement. For example:

import "my-wdl-in-the-root-directory.wdl" as file_import1
import "my/wdl/sub/directory/example.wdl" as file_import2

Here's a complete example showing both http(s) and file-based imports workflow in WDL:


import "" as http_import
import "imports/imported.wdl" as provided_import

workflow my_workflow {

Note that we said "import "imports/imported.wdl" in the workflow so we must have a imports/imported.wdl structure in the imports file:

└── imported.wdl

A more common scenario might have the imports at the root of the


import "my_wdl_1.wdl"
import "my_wdl_2.wdl"


The mechanism to provide the ZIP file of resources to be imported differ between Run and Server mode.

In Run mode, a sample command to run workflow.wdl would be:

$ java -jar cromwell.jar run workflow.wdl --imports

In Server mode, pass in a ZIP file using the parameter workflowDependencies via the Submit endpoint.