Canu and the awkward fact that the long-read assembler everyone cites is over

Four stages, and the first one is a separate project

Canu is a fork of the Celera Assembler, designed for high-noise single-molecule sequencing such as the PacBio RS II and Sequel platforms or the Oxford Nanopore MinION.

The pipeline is hierarchical and runs in four steps. Overlaps in the high-noise sequences are detected using MHAP, which is a separate project with its own repository. Corrected sequence consensus is then generated. The corrected sequences are trimmed. And finally the trimmed corrected sequences are assembled.

That first step is worth a moment of attention, because it is where most of the compute goes and it is where the design diverges most from a short-read assembler. A noisy long read is not a clean sequence, so the assembler cannot simply look for exact matches between reads. It has to find overlaps that are approximately correct, which means a probabilistic overlap detector, and it has to correct the reads before it can trust them, and only then can it trim adapters and low-quality ends and finally lay the pieces out.

The order also explains why the tool is described as large and small genome capable. The same four stages work regardless of the size of the input, which is not a property you get for free from a pipeline with a fixed resource profile.

The primary language is C++, the documentation is hosted on readthedocs, and the homepage is canu.readthedocs.io.

The end of life notice is the most important paragraph

The project description carries a caution block that changes how every other line in the documentation should be read.

It says Canu has reached end of life, that it has not seen active development since around 2021, and that it has not been tuned or tested on more recent data. Then it gives the alternative: unless you are assembling reads from that era, use a more recent assembler such as Flye, Hifiasm or Verkko.

That is the maintainer telling you not to start a new project on it, and the alternatives named are the current state of the art for exactly the task Canu does. Flye and Hifiasm are both modern assemblers for noisy long reads, and Verkko comes from the same organisation, so the recommendation is not a pointer to an unrelated project.

The commit record and the release record do not line up with that statement, and both are worth reading. The last push to the repository was on 2026-09-10, so something has moved in the tree. The releases are v2.1.1 from 2020-10-19, v2.2 from 2021-08-27 and v2.3 from 2024-12-17, so the last tagged version is three years old even though commits continue.

The plausible reading is that the tree still receives fixes and maintenance without new versions being cut, which is a common pattern for a tool whose users are mostly reproducing older work. It also means that if you need a specific behaviour, master is what you get, and it has not been through a release cycle recently.

Download a binary, and never the zip archive

The installation section contains the single most useful piece of operational advice in the whole description, and it is a warning rather than a command.

Do not download the zip source code. It is missing files and will not compile, and the documentation calls this a known flaw with git itself, linking to the long-standing GitHub issue about zip archives of repositories.

The easiest way to get started is to download a binary release from the project's releases page. That is the recommended path and it is the one to take.

Installing with a package manager is not encouraged, but if you have no other choice two are given:

  * Conda: `conda install -c conda-forge -c bioconda -c defaults canu`
  * Homebrew: `brew install brewsci/bio/canu`

Note the wording. Not discouraged, not discouraged. The project is telling you that a package manager install is a fallback for a situation where the binary is not an option, and anyone maintaining a pipeline across many machines should read that as a recommendation to download and pin the binary yourself.

The third option is building from the latest unreleased source, with the caveat that this version has not undergone the same testing as a release and so may have unknown bugs or issues generating sub-optimal assemblies. That is a specific warning: not that it crashes, but that it quietly produces a worse assembly, which is a worse failure mode for an assembler.

Building from source on each platform, and the macOS trap

The source build is a make invocation in the src directory:

        git clone https://github.com/marbl/canu.git
        cd canu/src
        make -j <number of threads>

The platform notes are the substance here, and each one names a different dependency trap.

On Linux, development packages are needed, and installing libboost1.83-all-dev is advised as being more recent than the one included in Canu, though not required. The package list given for Ubuntu is:

          apt install zlib1g-dev libcurl4-openssl-dev libssl-dev liblzma-dev libbz2-dev

On FreeBSD, libboost is generally required from packages or ports, it compiles with either clang at version 14 or newer or gcc at 9 or newer, and it requires openjdk18. With clang, libboost must be installed from ports. With gcc, either the Canu-supplied or the ports-supplied libboost can be used, which is a two-line difference in the invocation:

          gmake CC=gcc9 CXX=g++9 BOOST=libboost    #  Canu-supplied boost
          gmake CC=gcc9 CXX=g++9                   #  Ports/packages supplied boost

MacOS Apple Silicon requires libboost plus either openjdk or oracle-jdk from homebrew, preferred, or MacPorts, and here is the sharp edge: it will compile with clang at 14 or newer or gcc at 9 or newer but will not compile with the standard Xcode compiler.

          make CC=gcc-11 CXX=g++-11 BOOST=libboost  #  Canu-supplied boost
          make CC=gcc-11 CXX=g++-11                 #  Ports/packages supplied boost

So on a Mac you need a separate compiler and a JAVA_HOME pointing at the homebrew openjdk:

          export JAVA_HOME=/opt/homebrew/opt/openjdk

MacOS Intel is probably the same as Apple Silicon but is not tested.

Running it, and the two citations that matter

The run section is short because the binary is self-contained.

    ../<architecture>/bin/canu

gives the brief command line help, and:

    ../<architecture>/bin/canu -options

gives the full list of parameters. The path pattern shows that the release layout keeps a separate binary per architecture in a bin directory, which is consistent with the advice to download a release rather than build.

The citation section is more than academic courtesy, because two of the three references are conditional on which mode you run.

The primary citation is Koren, Walenz, Berlin, Miller and Phillippy, Canu: scalable and accurate long-read assembly via adaptive k-mer weighting and repeat separation, published in Genome Research in 2017. The second is Koren, Rhie, Walenz and others on de novo assembly of haplotype-resolved genomes with trio binning, published in Nature Biotechnology in 2018, and it is marked as the one to cite if you use trio binning. The third is Nurk, Walenz, Rhie and others on HiCanu, accurate assembly of segmental duplications, satellites and allelic variants from high-fidelity long reads, published in Genome Research in 2020, marked as the one to cite if you use -pacbio-hifi.

So the library has distinct modes with distinct literature, and the citation you need depends on which one you turned on. That is a useful signal about how much specialisation is built in beneath the four stage outline.

What the project directory tells you about scope

The repository layout is compact for a project of this size, and it explains a lot.

At the top level there is a .github directory, a .gitmodules file, a .readthedocs.yml for the documentation build, and three licence-related files: README.license.GPL, README.licenses and the README itself. Then there are the documentation/ directory, scripts/, and src/, which is where the build happens.

Two things stand out. The .gitmodules file means the source depends on other repositories being pulled in, which is consistent with a codebase that borrows from Celera, and it also means a source checkout needs those submodules initialised or the build will fail in a way that looks like a compile error rather than a missing dependency.

The scripts/ directory is where the per-platform build and release handling lives, given the amount of platform-specific detail in the installation notes, and documentation/ holds the user guide material that gets published to readthedocs, with the quick start and tutorial pages the documentation points you to.

The README.licenses file and README.license.GPL are there because Canu is a fork of the Celera Assembler, which means the licence situation of the original project travels with the code. Canu is distributed under the GPL, and the project describes itself as free and open source software. Anyone planning to use it in a commercial pipeline needs to look at those files rather than assume, because a GPL assembler linked into a proprietary pipeline is a different proposition from a permissively licensed one.

There is also a Docker image, and the documentation is explicit about its status: an unsupported Docker image made by a third party is available, at a Docker Hub address, and it is not maintained by the project.

Editorial conclusion

Canu suits someone reproducing an assembly from the 2016 to 2021 era, or working on PacBio HiFi data with the version of the pipeline that supports it, because the code, the citation trail and the documentation are all still there and the four stage structure is well understood. It does not suit a new project, since the project itself says so and points at Flye, Hifiasm and Verkko, and it does not suit anyone who needs a maintained toolchain for new sequencing runs. Before you reach for it, read the end of life notice at the top of the project description, note that the last push was on 2026-09-10 while the newest release is v2.3 from 2024-12-17, and if you must build from source, install the binary release rather than the zip archive, which the documentation says is missing files and will not compile.

Frequently asked questions

Official sources

1. Issues
2. marbl/canu on GitHub
3. Project website
4. README
5. Releases