# bioconda-recipes: the recipe repository behind the bioconda channel > bioconda-recipes holds the Conda recipes that become packages on the bioconda channel for Linux and macOS. It is a contribution target, not an installer, and the docs live on bioconda.github.io rather than in the repository. **bioconda/bioconda-recipes** — Conda recipes for the bioconda channel. Nightly build status The nightly uploader jobs build any recipes that exist on master but were not successfully uploaded to the bioconda channel. - Repository: https://github.com/bioconda/bioconda-recipes - Website: https://bioconda.github.io - Stars: 1,869 · Forks: 4,122 - Language: Shell - License: MIT - Published: 2026-08-04 · Updated: 2026-08-18 · Language: en - Canonical page: https://hysenlabs.com/projects/bioconda-bioconda-recipes ## What bioconda-recipes is, and what it is not The repository is a collection of Conda recipes. Conda is described in the README as a platform- and language-independent package manager that handles distribution, installation and version management, and the bioconda channel is a Conda channel providing bioinformatics packages for Linux and macOS, on both x86_64 and aarch64/arm64. The recipes in this repository are what produce those packages. That distinction decides whether the project is relevant to you. If you want to install a bioinformatics tool, you do not clone bioconda-recipes. The README sends users to https://bioconda.github.io for the user guide and to https://bioconda.github.io/contributor/index.html for the developer guide. The repository itself is the build input, and its audience is people who package software rather than people who run it. The primary language is Shell, which is accurate in a narrow sense: the repository is a large tree of recipe directories plus scripts and CI configuration. The top level holds recipes/, scripts/, config.yml, GUIDELINES.md, CONTRIBUTING.md, FAQs.md, .circleci/, .github/ and several azure-pipeline files. There is no application to run, no server to start and no binary to compile from this checkout. ## How a recipe becomes an uploaded package The README describes one automated path in detail. The nightly uploader jobs build any recipes that exist on master but were not successfully uploaded to the bioconda channel. Failures are handled by opening a pull request against the affected recipe, which tells you the pipeline is not a silent self-healing loop: a broken recipe stays broken until someone fixes the recipe file. Build status is reported per architecture. The README lists linux-64 and osx-64 through Azure DevOps nightly uploader jobs, osx-arm64 through a GitHub Actions workflow at .github/workflows/nightly.yml, and linux-aarch64 through CircleCI with a note that login is required to view the overview. The asymmetry is worth noticing. Three of the four targets expose a public badge; the aarch64 view does not, so anyone tracking that architecture has to authenticate before they can see whether the nightly run passed. The repository also carries a build-fail-blacklist file at the top level. Its name is self-explanatory and the README does not describe its contents, so treat it as a mechanism you will encounter when a recipe is excluded from builds rather than one you should reason about from the README alone. ## Getting the channel set up and adding a first recipe There is no install command in the README. It states that users should visit https://bioconda.github.io for details, and that developers should visit https://bioconda.github.io/contributor/index.html. The repository is not something you install, so the practical first step is to read those two pages before touching the checkout. The only thing you can do locally without the website is clone the recipes repository, which is what a contributor works from. The README's own documentation link is the anchor for everything that follows. ```bash git clone https://github.com/bioconda/bioconda-recipes.git ``` Once cloned, recipes live under recipes/, one directory per package, and the developer guide at https://bioconda.github.io/contributor/index.html describes how a recipe is laid out and submitted. The repository also ships GUIDELINES.md and CONTRIBUTING.md at the top level, and a .mergify.yml file that indicates automated pull request handling. The README does not document the merge rules or the recipe format, so treat the website as the specification and the repository as the working tree. ## The contribution workflow and where it is documented The repository ships GUIDELINES.md and CONTRIBUTING.md at the top level, and the README defers the developer guide to the website rather than reproducing it. That is a deliberate split, and it has a cost: the checkout alone does not tell you how to add a recipe, so anyone working offline or reading the repository without following the link is missing the rules that govern a submission. What the layout does tell you is where a recipe lives. Everything is under recipes/, one directory per package, and the nightly job only picks up recipes that exist on master and were not successfully uploaded. A recipe that never lands on master is never built, and a recipe that builds but fails to upload gets retried by the nightly job rather than by a human. There is also a .mergify.yml file at the top level, which indicates automated pull request handling. The README does not describe the merge rules, so the file is the place to look rather than this description. ## Limitations: architecture coverage and the missing install documentation The first real constraint is platform. The channel covers Linux and macOS. The README names no Windows target, and the nightly matrix is linux-64, osx-64, osx-arm64 and linux-aarch64. If your users are on Windows, this channel is not the distribution route the README describes. The second is visibility. The linux-aarch64 nightly status is behind a CircleCI login, so a public badge does not exist for that architecture in the README. Anyone who wants to know whether aarch64 builds are healthy has to sign in, which makes that target harder to monitor from outside. The third is documentation placement. The README is short and points outward for both the user guide and the developer guide. There is no install command, no recipe template and no troubleshooting section in the README itself. If you need to know how a recipe is structured before you write one, the repository tells you to go to https://bioconda.github.io/contributor/index.html. Finally, this is the wrong tool if you want to distribute software to non-Conda users. The output is Conda packages on a Conda channel. Nothing here produces a container image, a system package or a standalone binary as a first-class artifact. ## Alternatives and how they differ in approach The closest comparison inside the same ecosystem is conda-forge, which is also a Conda channel built from recipes. The difference is scope rather than mechanism: bioconda is described in the README as a channel providing bioinformatics related packages, so its recipes target that domain, while conda-forge covers general-purpose software. If a package you need is general purpose rather than bioinformatics, conda-forge is the channel whose recipes cover it. Outside Conda, the difference is more fundamental. A language-native registry, such as PyPI for Python or CRAN for R, distributes source or wheels for one language and leaves system dependencies to the user. A Conda recipe describes a package for a platform, including its non-language dependencies, which is precisely why bioinformatics tools with C libraries, aligners and external binaries fit here. The trade-off is that the recipe has to be written and maintained per platform, and the nightly job exists because that maintenance is ongoing. For a maintainer deciding where to publish, the question is whether your users already work in Conda environments. If they do, a recipe here reaches them directly. If they do not, a language registry or a container image will reach them with less packaging work. ## Licence and the cost of keeping a recipe alive The repository is MIT licensed. That covers the recipes and the repository contents. It does not relicense the software the recipes build, and each recipe packages a separate upstream project under that project's own terms. If you are adding a recipe, the upstream licence is the one that matters for redistribution, and the repository's MIT file says nothing about it. Maintenance cost is the part the README makes visible without stating it. The nightly uploader exists because recipes drift: a new upstream release, a changed dependency, a build that stops working on one architecture. The README's instruction is to resolve any nightly failure with a pull request for the affected recipe. That is an ongoing obligation attached to every recipe you add, not a one-time submission. The upgrade path is the same mechanism. Recipes live on master, the nightly job builds what is on master and not yet uploaded, and a fix ships as a pull request. There is no separate release process for the repository itself, and the README does not document rollback for a package that has already been uploaded to the channel. ## Conclusion Adopt bioconda-recipes as a contribution target if you maintain bioinformatics software and want it distributed through the bioconda channel on Linux or macOS, x86_64 or aarch64/arm64. Do not clone it expecting to install tools: users install from the channel, and the README points to https://bioconda.github.io for that. Before opening a pull request, read GUIDELINES.md and CONTRIBUTING.md, check whether a recipe for the tool already exists under recipes/, and confirm the licence of the software you are packaging, because the repository's own MIT licence covers the recipes, not the tools they build. ## FAQ ### What is Bioconda? Bioconda is a Conda channel providing bioinformatics related packages for Linux and macOS, supporting x86_64 and aarch64/arm64 architectures. The bioconda-recipes repository hosts the recipes that produce those packages. ### How do I install Bioconda? The README does not give install commands and directs users to https://bioconda.github.io for the user guide. The bioconda channel is a Conda channel, so installation is handled through Conda rather than through this repository. ### How do I create a package using conda? For this channel, a package starts as a recipe under recipes/ in the bioconda-recipes repository. The README points developers to https://bioconda.github.io/contributor/index.html for the guide, and the repository also ships GUIDELINES.md and CONTRIBUTING.md. ## Sources - [Official documentation](https://bioconda.github.io) - [Official README](https://github.com/bioconda/bioconda-recipes#readme) - [Project repository](https://github.com/bioconda/bioconda-recipes) --- Hysen Labs editorial analysis, written from the project's own repository and release notes. Cite the canonical page: https://hysenlabs.com/projects/bioconda-bioconda-recipes