anvi'o: an interactive platform for analyzing and visualizing omics data

Artifacts on disk instead of a session in memory

anvi'o is described as an interactive analysis and visualization platform for omics data, and the word that matters is platform. It covers a wide spread of domains: the repository topics list genomics, metagenomics, metatranscriptomics, pangenomics, phylogenomics, population genetics, microbiology, microbial ecology and multi-omics integration.

The architectural decision that shapes everything else is the artifact model. anvi'o programs consume and produce artifacts, and those artifacts are files that persist on disk, so an analysis is a sequence of steps that leave behind inspectable results rather than a monolithic program that runs and exits. The help pages are organised around this, describing individual anvi'o programs as well as the artifacts they consume or produce.

That design has real consequences for practice. A step can be re-run, a result can be revisited, and two analyses can be compared, because the intermediate state is not trapped in memory. It also means a learning curve, since artifacts carry identity and version information and programs check them. An artifact produced by a newer anvi'o version is not silently consumed by an older program.

The audience is researchers in microbial genomics and related fields who want both a scripted command line path and a way to explore the results graphically. The repository is developed by the Anvi'o Development Team with named maintainers, and the site describes it as having tutorials, help pages and a community Discord.

A program suite with a web interface on top

The repository layout shows both halves of the system. There is an anvio/ package directory, which holds the code, and the package metadata declares both a console environment and a web environment, with the classifiers listing Environment :: Console and Environment :: Web Environment. There is a Dockerfiles/ directory for container builds and an interactive images directory inside the package for the visual assets of the browser interface.

The dependency list in pyproject.toml shows what each half is built on. For the analysis side there is numpy and scipy, pysam for reading sequencing data, ete3 for trees, scikit-learn, statsmodels, pandas, numba, snakemake for workflow orchestration, and pyani for average nucleotide identity comparisons, which is a metagenomics-specific measure. For the interface there is bottle, a small WSGI web framework, and django, plus mistune for Markdown rendering, plotext for terminal plots and rich-argparse for command line help.

The mix of a small web framework and a large one is worth flagging. Django is almost certainly not serving the interactive pages, since bottle is a much better fit for a local analysis server, and django is more plausibly used for a web-facing component. The repository does not explain the split, and ARCHITECTURE.md is the place the project points developers to for a sense of the design, coding patterns and idioms.

For a user, the split shows up as a choice between running programs from a shell and opening an interactive view of the artifacts those programs produced.

Python 3.10 pinned exactly, with old scientific pins

The install story is constrained in a way that catches people out. The project metadata states:

requires-python = "==3.10.*"

That is an exact pin on a single minor version of Python, not a lower bound. A machine with 3.11 or 3.12 will not satisfy it, and the environment has to be built around 3.10 specifically.

The scientific stack is pinned just as tightly in places. numpy is held at 1.24.1, matplotlib at 3.5.1, pandas at 1.4.4 and scikit-learn at 1.2.2, while scipy, ete3, statsmodels and others float. The reason is a familiar one in scientific software, since newer versions of these libraries change behaviours and break the pinned combinations, and the maintainers have chosen to freeze the ones that matter for reproducibility of existing analyses.

The other dependencies reveal the domain. illumina-utils handles sequencing data processing, snakemake provides the workflow layer that long pipelines need, multiprocess and numba exist for performance on large analyses, psutil reports on system resources, tabulate and colored format tabular and coloured output, and paste is a small utility for column-wise text work.

For an adopter, the practical consequence is that you plan the environment before you plan the analysis. The repository carries a .conda/ directory, a pyproject.toml as the build configuration, a ruff.toml for linting, and a .pre-commit-config.yaml, which together describe a project that expects you to work inside a controlled Python 3.10 environment rather than a shared system interpreter.

Documentation lives on anvio.org, not in the repository

The README is short, and it is a set of pointers rather than a manual. Installation manuals, user tutorials and the rest are on the anvi'o project page at anvio.org. The program-level help pages at anvio.org/help describe individual programs and the artifacts they consume or produce. Stable releases are listed on the GitHub releases page.

For a platform this large, that split makes sense. The documentation site is where per-program reference pages belong, and the help pages organised by artifact are the right shape for a tool whose central concept is the artifact.

It also means the repository alone will not get you running. The README does not contain an installation command, a usage example or a configuration snippet. Anyone evaluating anvi'o has to go to anvio.org for the installation manuals, and that is the step to take first, since the environment requirements are tight enough that following the manual rather than improvising is the sensible route.

Two other pointers matter for a new user. The Discord channel is where community questions go, and the tutorials section at anvio.org/learn is where workflows are taught. For developers, ARCHITECTURE.md is the recommended starting point to get a sense of the design, the coding patterns and the idioms, which is a strong hint that the codebase is large and that a contributor is expected to read before writing.

Release cadence with long gaps between major versions

The release history is worth understanding before you pin a version. The listed releases are v9, named eunice, on 2026-01-19, v8, named marie, on 2023-09-27, and v7.1 on 2021-10-20.

Those are big gaps between major versions, on the order of two years or more, and the names given to the versions are worth pausing on. A named major release in a project like this usually signals a change in the artifact format or the on-disk layout, and since the artifact model is the backbone of the platform, an artifact written by one major version is not something an older major version will read.

The last push to the repository was on 2026-10-20, and the project is not archived, so development continues between the tagged majors. A CI badge for daily component tests sits at the top of the README, which is a useful signal for a platform where the artifact interactions are the hard part.

The practical rule is that you should not mix anvi'o program versions casually within one analysis. Check the version stamp on the artifacts you are combining, and use a single anvi'o release across the steps of a given analysis.

The licence is GPL-3.0-or-later, recorded in the package metadata and in a LICENSE.txt file at the root. The AUTHORS.txt and CHANGELOG.md files at the root, plus a NEWS.md, are where the project keeps credit, the change history and the announcements.

Where anvi'o is the wrong tool

There are clear cases where this platform is the wrong choice, and knowing them saves weeks.

The first is a different Python version. The pin is exact, and the frozen scientific libraries mean you cannot simply upgrade the interpreter or the stack to a newer environment without moving away from the supported combination.

The second is a lightweight need. If you need one plot of one comparison and you already have a working Python data stack, anvi'o is enormous by comparison. Its dependency list includes snakemake, pysam, ete3, numba and django, and the platform assumes an analysis workflow with artifacts that persist between steps. Pulling that in to produce a single figure is a lot of installation for a small job.

The third is a graph-first, artifact-later workflow. The interactive interface renders artifacts that anvi'o programs produced, so the order is fixed: programs first, then the view. If your instinct is to load data, explore it interactively and then decide what to compute, that is the opposite of how this platform is built, and the cost of that mismatch is real.

The fourth is a closed, non-reproducible environment. The repository ships Dockerfiles, which is the right sign for people who need a reproducible container, but the container path is one option among several rather than the only one. If you cannot run either the documented conda environment or a container, this is a difficult platform to get going.

A note on scope as well. The repository lists multi-omics integration as a keyword and a science audience, but the tools are not a general statistical package, and the visualisations are tied to the artifact model rather than to a standalone plotting API.

Editorial conclusion

Adopt anvi'o if you are doing comparative genomics, metagenomics or related multi-omics work and want an interactive interface over your results plus a command line layer that can be scripted. Do not adopt it for a one-off analysis on a machine you cannot bring to Python 3.10, since the package pins that version exactly, and do not expect a general-purpose plotting library, since the visualization is built around anvi'o's own artifact model. Verify first that the version you install matches the anvi'o program versions you intend to mix, because artifacts carry a version stamp that older programs will refuse, and read ARCHITECTURE.md before extending the code.

Frequently asked questions

Official sources

1. License: GPL-3.0
2. merenlab/anvio on GitHub
3. Project website
4. README
5. Releases