# BioContainers holds approved container recipes for many bioinformatics tools > BioContainers/containers is a repository of prebuilt container recipes for bioinformatics software, generated per tool directory and published to Docker Hub and Quay under the biodckr organisation. It works as a catalogue of reproducible environments rather than a single tool, and the request flow is a GitHub issue. **BioContainers/containers** — Bioinformatics containers - Repository: https://github.com/BioContainers/containers - Website: http://biocontainers.pro - Stars: 816 · Forks: 266 - Language: Dockerfile - License: Apache-2.0 - Published: 2026-10-20 · Updated: 2026-10-20 · Language: en - Canonical page: https://hysenlabs.com/projects/biocontainers-containers ## A catalogue, one directory per tool BioContainers/containers is a repository of approved bioinformatics containers, and the layout makes the shape of it obvious. The top level is a very long list of directories, one per tool, with names like abacas, abyss, adapterremoval, ariba, augustus, autodock, bamtools, bamdst and ballview. Each directory holds the recipe for that one piece of software. That granularity is the point. A bioinformatics pipeline often stitches together a dozen or more tools, each with its own dependencies and its own version, and the version combinations are where analyses stop being reproducible. Containerising each tool separately and pinning each one means a pipeline becomes a list of image references rather than a pile of environment specifications. The repository is Apache-2.0 licensed, its primary language is Dockerfile, and the project has a single release tag, Crux, from 2019. The homepage is biocontainers.pro, and the topics name the architecture, the bioinformatics focus, docker images, dockerfiles and rkt. ## The project is community driven with written specifications The README is a project description rather than a usage guide, and it points at a separate specification repository for the rules. The project definition lives in the BioContainers/specs repository, the contribution rules are in that repository's CONTRIBUTING.md, and there is a wiki for the project as well. The stated origin is the idea of using container technologies such as Docker or rkt for bioinformatics software, on the grounds that a common and controllable environment for running software helps with the problems of software development and distribution. It describes itself as a community driven project providing the infrastructure and basic guidelines to create, manage and distribute bioinformatics containers, with a special focus on omics fields such as proteomics, genomics, transcriptomics and metabolomics. The objectives are listed as a series of deliverables: a base specification and images for building new bioinformatics software, a series of ready to use containers for the community, a set of guidelines and specifications for building standardised containers that combine with other containers and tools, and a complete infrastructure to develop, deploy and test new containers using continuous integration suites such as Travis or Shippable, or manually built solutions. The licence is Apache 2, and the contact address given in the README is a mailing list for the project. ## Two registries, and the tags are versions not latest BioContainers are listed in two main registries. Docker Hub holds the Docker based containers under the biodckr organisation, and Quay Hub holds Docker and rkt based containers that can use the rkt infrastructure. The image naming in the README is worth noting because it is old enough to trip up an automated lookup. The organisation is spelled biodckr, which is not the same as the BioContainers project name, and the two registries split by runtime rather than by content. The request flow is a GitHub issue. Users can request a container by opening an issue in the containers repository, and the README notes that in the previous workflow this was done differently. The point of the current arrangement is that the request is tracked in the same place as the recipes, so a request and the resulting container directory live in one history. There is also a shortcut. A Bioconda package automatically builds a related container, so if you are looking for a container for a Bioconda package, a container on quay.io should already exist, and the package documentation points at it. The one condition attached to that route is important: you have to use the needed tag version, because no latest tag is available. ## Containers versus virtual machines, and the reproducibility argument The README explains containers in a way that is dated but still accurate in substance. Containers are built from existing operating systems, and they differ from virtual machines because they do not possess an entire guest OS inside. Instead they are built using optimised system libraries and use the host OS memory management and process controls, and they are normally centralised around a specific software, becoming executable by instantiating images from them. The argument for using them in bioinformatics is stated in the section on what you need a container for. When a bioinformatics analysis is performed, several bioinformatics tools and software should be installed and configured, and that process can take several hours and demand a lot of effort, including the installation of multiple dependencies and tools. The reproducibility goal is spelled out in the objectives as well: providing guidelines and help on how to create reproducible pipelines by defining, reusing and reporting specific container versions which will consistently produce the exact same result and always be available in the history of the container. The last clause is the interesting one. The requirement is not just that a version exists, but that it remains retrievable, so that a paper published in 2021 can still be re-run in 2026. That is a different design goal from building images for the latest release. ## What a recipe directory actually contains The top level of the repository holds a few project-wide files alongside the tool directories. There is a MANIFEST.md, a PULL_REQUEST_TEMPLATE.md, a LICENSE, a .gitmodules file, a .github directory and the README itself. The MANIFEST.md is the one to look at first, because it is the record of what a given container is supposed to be, and the pull request template is the mechanism that enforces the same discipline on incoming recipes. A project that accepts hundreds of community contributed container definitions needs a checklist, and a template is how that checklist gets applied consistently. The .gitmodules file suggests some recipes pull in shared content, and the .github directory holds the workflows that build and test the images after a change lands. The recipes themselves are Dockerfiles, which is why the repository lists Dockerfile as its primary language rather than a programming language. A Dockerfile for a bioinformatics tool has a fairly predictable shape: a base image, the tool built or copied in, the dependencies that came with it, and a command that runs the tool. The value of the collection is that someone has already worked out that shape for each tool, including the ones with awkward dependencies. ## The documentation split and where the details live The README is short and sends readers elsewhere for everything else. The latest information about the project is at BioContainers.pro, the full documentation for using the containers to perform bioinformatics analysis is at the biocontainers-edu site, and the workflow diagrams and the container overview image are hosted in the specs repository rather than in this one. That split is a little awkward to get around. The container list itself, the thing most people want, is not in the README at all; it is the directory listing at the top of the repository, which is exactly the format a search engine or a script can read but a human cannot skim. There is also a community chat linked in the README, on Gitter, and the project asks for contributions of new containers and for help in deploying containers for researchers who do not have bioinformatics support. The practical upshot is that this repository is a data set with a workflow around it, and a person using it will spend time in the specification repository, the wiki and the education site rather than in the recipe directories. Anyone picking this up should expect to read the specs to understand what a well formed container is supposed to contain. ## Conclusion BioContainers suits a bioinformatician who needs a specific analysis tool to run with a fixed dependency set on a laptop, an HPC cluster or in the cloud, since each tool has its own recipe directory and the images are pinned by version rather than by a floating latest tag. It is the wrong tool if your software is not a packaged bioinformatics tool, and it does not cover the pipeline orchestration around your analysis. Before relying on it, pick one tool directory, read its recipe and its MANIFEST.md, and pin the version tag you need, because the documentation is explicit that no latest tag is published. ## FAQ ### Where are BioContainers published? They are listed in two main registries, Docker Hub for the Docker based containers and Quay Hub for the Docker and rkt based ones, both under the biodckr organisation. The README also notes that a Bioconda package automatically builds a related container on quay.io. ### How do I request a new BioContainer? Users can request a container by opening an issue in the containers repository, and the README notes that in the previous workflow this was done differently. Contribution rules live in the BioContainers/specs repository. ### Can I use a latest tag for a BioContainer? No. The README is explicit that you have to use the needed tag version, because no latest tag is available. That is deliberate, since the project aims for container versions that stay available in the history so a published result can still be reproduced. ## Sources - [BioContainers/containers on GitHub](https://github.com/BioContainers/containers) - [License: Apache-2.0](https://github.com/BioContainers/containers/blob/master/LICENSE) - [Project website](http://biocontainers.pro) - [README](https://github.com/BioContainers/containers/blob/master/README.md) - [Releases](https://github.com/BioContainers/containers/releases) --- Hysen Labs editorial analysis, written from the project's own repository and release notes. Cite the canonical page: https://hysenlabs.com/projects/biocontainers-containers