# Cromwell: a workflow management system for WDL, and the backends you have to run yourself

> Cromwell is the Broad Institute's open source workflow management system for bioinformatics, executing WDL workflows through pluggable backends and packaging them for the cloud. The engine is open and well documented, but from version 80 onwards CWL is gone, and backends other than the ones the team is actively developing are community maintained.

**broadinstitute/cromwell** — Scientific workflow engine designed for simplicity & scalability. Trivially transition between one off use cases to massive scale production environments

- Repository: https://github.com/broadinstitute/cromwell
- Website: http://cromwell.readthedocs.io/
- Stars: 1,085 · Forks: 382
- Language: Scala
- License: BSD-3-Clause
- Published: 2026-10-19 · Updated: 2026-10-19 · Language: en
- Canonical page: https://hysenlabs.com/projects/broadinstitute-cromwell

## What Cromwell is: a workflow management system for bioinformatics, not a workflow author

The repository describes Cromwell as an open-source Workflow Management System for bioinformatics, and the project description calls it a scientific workflow engine designed for simplicity and scalability, with the claim that it transitions trivially between one-off use cases and massive scale production environments. The wording of that claim tells you what the software does and does not do. Cromwell does not describe the workflow language, it executes it. The WDL language itself is developed in a separate project, the openwdl/wdl repository, and the README distinguishes the two communities by pointing at a Cromwell Slack workspace for the engine and an OpenWDL Slack workspace for the language. Cromwell supports the WDL workflow language, and the language support page is linked from the documentation. For a team that has already written its pipelines in WDL, the engine is the missing runtime rather than the missing model.

## Backends are the extension point, and the team is narrowing the ones it maintains

The mechanism that lets one workflow definition run in different places is the backend. The README says Cromwell uses modular backends to support different cloud vendors, and that the team is currently developing for AWS Batch and GCP Batch, while maintenance of other backends is community based. That sentence is the single most important operational fact in the README. The engine is a shared codebase, but a backend is where the work happens, so a community maintained backend inherits the risk. The repository layout makes the structure visible: there is a backend/ directory, a supportedBackends/ directory, a cromwell.example.backends/ directory that evidently holds reference configurations, and a cloudSupport/ directory for vendor specific code. There is also a cloud-nio/ directory, which by name suggests the non blocking IO layer, and a docker/ directory and dockerHashing/ directory for container handling. A self-managed deployment therefore means picking both a backend and a way of storing and hashing the container images your tasks reference.

## Version 80 dropped CWL, and the WDL ecosystem is where the language questions go

The README states that Cromwell version 80 and above no longer support CWL. For an evaluation, this is a one-way door that has already closed rather than a future risk. A pipeline estate written in CWL needs migration or a different engine, and the README points at the WDL repository for the language itself. The documentation also has a dedicated site at cromwell.readthedocs.io with a stable version path, and the first-time path is the FiveMinuteIntro tutorial, which suggests the project assumes a fairly quick onboarding for a single workflow before you go near the harder topics. The Ecosystem page is worth noting for the same reason: the README describes a growing ecosystem of community-backed projects, which in practice is where integrations live that the core team does not build.

## Where to get it, and what support you get if you self-manage

There is a hosted option and a self-managed one, and the README distinguishes them clearly. Many users run their WDL workflows in Terra, a managed bioinformatics platform with built-in Cromwell support. Users with specialised needs who want to install and maintain their own instance can download a JAR or a Docker image from the releases page. The support statement is the part to read twice: the development team accepts reproducible bug reports from self-managed instances but cannot provide direct support. So a self-managed Cromwell is something you operate, with the upstream team reachable through GitHub Issues and a security contact at infosec@broadinstitute.org for anything that looks like a vulnerability. The repository also carries a Contributor Guide for code contributions, a CHANGELOG.md, a RELEASE_PROCESS.md, a CITATION.md for citing the work, and an AUTHORS file, which is a sign of a project with real process around it.

## The code layout tells you this is a server, not a library

The top level of the repository reads like the module map of a long lived Scala project, and the module names are the architecture. There is a server/ directory, a services/ directory, an engine/ directory, a core/ directory, a database/ directory, a wom/ directory that by the naming convention holds the workflow object model, a languageFactories/ directory for the WDL implementation, a wdl/ directory, a womtool/ directory, a filesystems/ directory, a codegen_java/ directory, a cromwellApiClient/ directory, and a cromwell-drs-localizer/ directory. Two of those are worth flagging for a reader who is not a Scala developer. The presence of a database/ module tells you workflow metadata is persisted rather than kept only in memory, which is what allows a restarted server to pick up where it left off. The presence of both build.sbt and .scalafmt.conf, together with .sdkmanrc, shows a pinned toolchain and a formatting standard that CI can enforce, and the docker/ directory plus a container image release path ties back to the containerised execution model that most bioinformatics workflows require.

## Licensing, releases and the develop branch default

The README states that licensing is BSD 3-Clause, and the repository carries a LICENSE.txt for that. There is a separate LICENSE-ASL-2.0 file as well, so a careful reader should confirm which terms attach to which components before redistributing. On versions, the releases are numbered 90 on 2025-05-27, 91 on 2025-10-08 and 92 on 2026-01-30, which is a steady release cadence for a piece of infrastructure that runs production pipelines. The last push to the repository was on 2026-10-14, and the default branch is develop rather than a release branch, which is the detail that matters operationally: a self-managed instance should be pinned to a numbered release or a tag, not to develop, because develop carries unreleased work and a metadata schema change will be harder to absorb than a normal upgrade.

## Conclusion

Cromwell suits a bioinformatics team that has settled on WDL as its workflow language and wants a single engine that can run the same workflow on a laptop and on a cloud batch service, and that is prepared to run and maintain its own instance. It is a poor fit for a team whose workflows are written in CWL, because version 80 and above no longer support that language, and a poor fit for anyone who wants vendor support for a self-managed instance, because the development team states it accepts reproducible bug reports but cannot provide direct support. Before adopting it, read the Ecosystem page for the community projects around backends and on-premises deployment, pick the backend whose maintenance you are willing to own, and check the CHANGELOG.md and RELEASE_PROCESS.md in the repository before pinning a version, since the default branch is develop rather than a release branch.

## FAQ

### What is Cromwell used for?

Cromwell is an open-source Workflow Management System for bioinformatics that executes WDL workflows through pluggable backends. It is the engine, not the workflow language: WDL itself is developed in the separate openwdl/wdl repository.

### Which backends does Cromwell support and who maintains them?

The README says Cromwell uses modular backends to support different cloud vendors, that the team is currently developing for AWS Batch and GCP Batch, and that maintenance of other backends is community based. The repository includes backend/, supportedBackends/ and cromwell.example.backends/ directories.

### Does Cromwell still support CWL workflows?

No. The README states that Cromwell version 80 and above no longer support CWL, so a pipeline estate written in CWL needs migration or a different engine.

### How do I install and run Cromwell myself?

Users with specialised needs can download a JAR or a Docker image from the GitHub releases page and maintain their own instance, and many users instead run WDL workflows in Terra, a managed bioinformatics platform with built-in Cromwell support. The documentation site at cromwell.readthedocs.io has a FiveMinuteIntro tutorial for the first run.

### What support does the Cromwell team provide for self-managed instances?

The development team accepts reproducible bug reports from self-managed instances but cannot provide direct support. Issues are filed on GitHub Issues, and security issues can be reported to infosec@broadinstitute.org.

## Sources

- [broadinstitute/cromwell on GitHub](https://github.com/broadinstitute/cromwell)
- [License: BSD-3-Clause](https://github.com/broadinstitute/cromwell/blob/develop/LICENSE)
- [Project website](http://cromwell.readthedocs.io/)
- [README](https://github.com/broadinstitute/cromwell/blob/develop/README.md)
- [Releases](https://github.com/broadinstitute/cromwell/releases)

---

Hysen Labs editorial analysis, written from the project's own repository and release notes. Cite the canonical page: https://hysenlabs.com/projects/broadinstitute-cromwell