---
title: 'Infrastructure'
---

import { RecipeTabs } from "@site/src/components/RecipeTabs";

# Infrastructure

This page gives an overview of the conda-forge infrastructure, that is, an account of the various pieces maintained by the conda-forge contributors as well as third-party providers that collectively form the basis for the operation of conda-forge.

We start with the different Github [repositories](#repositories) maintained by conda-forge itself, then describe the administrative commands available for use in those repositories, the so-called [Admin web services](#admin-web-services), followed by [the CI services](#ci-build-services), i.e. the third-party providers used for building and maintaining packages together.
After that, we turn to a description of some aspects of the build environment for packages in [Compilers and Runtimes](#compilers-and-runtimes), together with [details about the upload to the package server](#output-validation-and-feedstock-tokens).

[Then](#stages-of-package-building-and-involved-infrastructure), we see how the process of building a package interacts with different parts of the infrastructure.

We close out with a brief [listing of involved entities](#inventory-of-services--providers).

## Repositories

### Staged-recipes

This repository is the gateway to conda-forge and where users can submit new recipes which, once reviewed and accepted, will generate a new feedstock and team.
You can find the detailed guide for submitting new package recipes in [The staging process](../adding_pkgs#the-staging-process).

- ⚙️ Deployed in [`conda-forge/staged-recipes`](https://github.com/conda-forge/staged-recipes)
- 🔒 Has access to Anaconda.org (cf-staging)
- 🤖 Integrated with [`webservices`](#webservices)

#### Anatomy of staged-recipes

`recipes/` contains one or more _subdirectories_ with user-submitted recipes.
Most cases will only submit one recipe at a time, but if several subdirectories are present, the `build_all.py` script will build them in the right order so dependencies are satisfied.

`.ci_support` contains the conda-build YAML configuration files, but in this case (if compared to feedstocks), you will also find some scripts:

- `build_all.py`: Calls conda-build in the right (topographically sorted) order.
- `compute_build_graph.py`: Supports `build_all.py` by providing the job graph with all the submitted recipes.

The YAML files included in `.ci_support` are minimal and not rendered like the ones you find in feedstocks.
Instead, conda-build will take these and combine them with the pinnings from `conda-forge-pinning` at runtime.
Also note that `staged-recipes` only builds for x64. Support for additional architectures can only be done once a feedstock has been provided.

- Linux: `linux64.yaml` plus the CUDA variants.
- macOS: `osx64.yaml`.
- Windows `win64.yaml`.

The directory `.scripts` contains roughly the same shell scripts that would be used in a feedstock for the CI pipelines.
However, since `staged-recipes` does not support rerendering, these are kept in sync manually and it is common to see some differences.

#### Workflows

The main job run on `staged-recipes` is the `conda-build` job that runs on every PR (and push to `main`) to check whether the recipes build packages correctly.
These jobs run on Azure Pipelines defined in [`.azure-pipelines/`](https://github.com/conda-forge/staged-recipes/tree/main/.azure-pipelines).

The actual creation of the feedstock is run in [conda-forge/admin-requests](#admin-requests).

Additional workflows help users set up their recipes correctly. They react to events in PRs:

- [`staged-recipes-linter`](https://github.com/conda-forge/staged-recipes/blob/main/.github/workflows/staged-recipes-linter.yml): General recipe linting plus some staged-recipes specific checks, like not editing the examples.

External services connect to `staged-recipes` too:

- The `@conda-forge-admin` bot (deployed at [`webservices`](#webservices)) will lint and provide hints in PRs based on the contents of the recipe.

### Feedstocks

- ⚙️ Deployed in Github repositories
- 🔒 Has access to Azure Pipelines, Github Actions, Anaconda.org (cf-staging)
- 🔐 Might have access to Travis CI, Cirun via `admin-requests` (WIP)
- 🤖 Integrated with [`admin-migrations`](#admin-migrations), [`admin-requests`](#admin-requests), the [`conda-forge-bot`](#conda-forge-bot), and [`webservices`](#webservices).

Conda-forge has thousands of feedstocks.
Each feedstock hosts a recipe plus the required pipelines, supporting scripts and configuration metadata.

The contents of a feedstock are well specified. Only two locations are user-managed:

- `recipe/`: Contains the conda-build instructions to build packages. It needs, at least, a `meta.yaml` file, and this is also where the optional `conda_build_config.yaml` usually goes.
- `conda-forge.yml`: This is the feedstock configuration file.

:::warning
You should never manually edit files _not_ listed above! Changes will be overridden in the next feedstock rerender.
:::

Combining these two sources with some external components, `conda-smithy` will generate (render) the contents of the feedstock. Many of the directories are named like that because it is what the external service (e.g. Azure) requests. However, some `conda-smithy`-unique directories are worth discussing:

- `.ci_support/`: Contains the rendered `conda_build_config.yaml` files, passed to `conda-build` via the `-m` flag. Each file here corresponds to one job in the CI build matrix.
- `.ci_support/migrations/`: Special YAML files that instruct `conda-smithy` how to update the `.ci_support/*.yaml` files. These migration files are usually put here by the [`conda-forge-bot`](#conda-forge-bot) infrastructure, and removed once the migration is considered finished.
- `.scripts/`: Common logic and code supporting the steps you can find in the CI pipelines and local debugging tools.
- `build-locally.py`: A Python script to debug recipes in your machine, roughly equivalent to what's done in the CI pipelines.

:::info Learn more (WIP)

- Rerendering a feedstock
- Recommended workflow

:::

#### feedstocks monorepo

A single repository containing all feedstocks as submodules.

- ⚙️ Deployed in [`conda-forge/feedstocks`](https://github.com/conda-forge/feedstocks)

#### feedstock-outputs

This repository is a registry of feedstock names and the packages (artifacts) they produce.

- ⚙️ Deployed in [Github Actions via `conda-forge/feedstock-outputs`](https://github.com/conda-forge/feedstock-outputs)
- 🔒 Has access to Azure, Anaconda.org (cf-staging)

Its main purpose is to provide an allow-list for the validation server to prevent malicious cross-feedstock builds, although it's also an informative map of `feedstocks <-> packages` that is exposed in the [packages section of the website](https://conda-forge.org/feedstock-outputs/).

### cdt-builds

- ⚙️ Deployed in [Azure Pipelines](https://dev.azure.com/conda-forge/cdt-builds/_build) via [`conda-forge/cdt-builds`](https://github.com/conda-forge/cdt-builds)
- 🔒 Has access to Azure Pipelines, Anaconda.org (cf-staging)

This special repository builds Core Dependency Tree packages for conda-forge (Linux only).
It doesn't use the feedstock automated machinery.
Instead, it has its own Azure Pipelines workflow and a well-documented README.

### msys2-recipes

- ⚙️ Deployed manually from [`conda-forge/msys2-recipes`](https://github.com/conda-forge/msys2-recipes)

This is a fork of the old community recipes repository at Anaconda, which includes the `msys2` recipes under the [`msys2/`](https://github.com/conda-forge/msys2-recipes/tree/main/msys2) directory.
Note also the supporting scripts in the [`common-scripts/`](https://github.com/conda-forge/msys2-recipes/tree/main/common-scripts) folder.

### Website

The current [conda-forge.org](https://conda-forge.org) is a statically generated website published to Github Pages.

- 📜 Source at [conda-forge/conda-forge.github.io](https://github.com/conda-forge/conda-forge.github.io/)
- ⚙️ Deployed in [conda-forge.org](https://conda-forge.org/)
- 🤖 to enhance the utility of the documentation we also use
  - PR previews at [Netlify](https://app.netlify.com/sites/conda-forge-previews)
  - Statistics at [GoatCounter](https://conda-forge.goatcounter.com/)
  - Search powered by [Algolia](https://dashboard.algolia.com/apps/KB43FQOB7U/dashboard)

The documentation is built with Docusaurus and the source files are located in the [`docs/`](https://github.com/conda-forge/conda-forge.github.io/tree/main/docs) directory of the repository.

If you find any typos, errors, unclear explanations, or new topics that can be covered, you can suggest changes to the documentation. For more details, please refer to [Improve the documentation](/docs/user/contributing/#improve-the-website).

In addition to the static documentation, the website also offers information on the current status of conda-forge as well as a mapping of packages to feedstocks.

- Status: [conda-forge.org/status](https://conda-forge.org/status)
- Packages-to-feedstock mapping: [conda-forge.org/feedstock-outputs](https://conda-forge.org/feedstock-outputs)

### Metadata repositories

These are repositories that primarily hold metadata used by other parts of the conda-forge ecosystem.

#### conda-forge pinning

Hosts the global pinnings for conda-forge, and the ongoing migrations.

- ⚙️ Deployed in [Anaconda.org](https://anaconda.org/conda-forge/conda-forge-pinning) via [`conda-forge/conda-forge-pinning-feedstock`](https://github.com/conda-forge/conda-forge-pinning-feedstock)
- 🔒 Has access to Azure, Anaconda.org (cf-staging)

Package-wide dependency pins are defined in [conda_build_config.yaml](https://github.com/conda-forge/conda-forge-pinning-feedstock/blob/main/recipe/conda_build_config.yaml) in the [conda-forge/conda-forge-pinning-feedstock](https://github.com/conda-forge/conda-forge-pinning-feedstock).

For more information on conda-forge wide package pins, please refer to [Globally pinned packages](pinning_deps.mdx#globally-pinned-packages).

Please open a [PR](../glossary.md#pr) and/or an issue there, if you think a pin needs to be advanced. For more information on updating globally pinned packages, please refer to [Updating package pins](pinning_deps.mdx#updating-package-pins).

#### conda-forge-repodata-patches

This repository creates the `repodata.json` patches used by the Anaconda.org to amend the metadata coming from the published packages.

- ⚙️ Deployed in [Anaconda.org](https://anaconda.org/conda-forge/conda-forge-repodata-patches) via [`conda-forge/conda-forge-repodata-patches-feedstock`](https://github.com/conda-forge/conda-forge-repodata-patches-feedstock)
- 🔒 Has access to Azure, Anaconda.org (cf-staging)

#### conda-forge-ci-setup

This special feedstock provides a package that defines the logic to install and configure a common CI setup across providers.

- ⚙️ Deployed in [Anaconda.org](https://anaconda.org/conda-forge/conda-forge-ci-setup) via [`conda-forge/conda-forge-ci-setup-feedstock`](https://github.com/conda-forge/conda-forge-ci-setup-feedstock)
- 🔒 Has access to Azure, Anaconda.org (cf-staging)

#### conda-forge/conda-forge-bot-data

This is the graph data used by [`conda-forge-bot`](#conda-forge-bot).

- ⚙️ Deployed in [Github Actions via `conda-forge/conda-forge-bot-data`](https://github.com/conda-forge/conda-forge-bot-data)
- ⛓ Needs [`conda-forge/conda-forge-bot`](#conda-forgeconda-forge-bot), [`conda-forge/conda-forge-pinning-feedstock`](#conda-forge-pinning)
- 🤖 Uses [`@regro-cf-autotick-bot`](#bot-accounts)
- 🔒 Has access to Github API

The logic to build the graph is provided by [`conda-forge-bot`](#conda-forgeconda-forge-bot).

#### docker-images

This repository builds the Docker images used to provide a unified system on all Linux builds.

- ⚙️ Deployed in [`conda-forge/docker-images`](https://github.com/conda-forge/docker-images)
- 🔒 Has access to [DockerHub](#docker-hub) and [Quay.io](#quay)
- ⛓ Needed by `staged-recipes`, feedstocks.

### Code repositories

These are repositories that hold programs and other codes that define behavior.
However, their actions are often not triggered here, but rather used by other parts of the conda-forge ecosystem.

#### Smithy

This is the main feedstock creation and maintenance tool.

- 📜 Source at [`conda-forge/conda-smithy`](https://github.com/conda-forge/conda-smithy)
- 📦 Packaged at [`conda-forge/conda-smithy-feedstock`](https://github.com/conda-forge/conda-smithy-feedstock)
- 📖 [Documentation](https://github.com/conda-forge/conda-smithy/blob/main/README.md)
- 📖 [conda-forge.yml Documentation](https://conda-forge.org/docs/maintainer/conda_forge_yml/)

Most of its usage is automated by our infrastructure:

- Feedstock creation and services registration at [`staged-recipes`](#staged-recipes)
- Regeneration (rerendering), linting and hinting in PRs done by `conda-forge-admin` on [`webservices`](#web-services)

However, you can also use it locally or on your forge-like deployments. For local debugging, you will find these commands useful:

- `conda-smithy rerender`
- `conda-smithy recipe-lint`

Smithy contains maintenance code for conda-forge, which is used by the `conda-smithy` command line tool and the [Admin web services](#admin-web-services).

`conda-forge/conda-smithy` is the right repository to report bugs for

- The rerendering process
- The recipe linter
- [CI](../glossary.md#ci) support utils

`conda-smithy` also contains the command line tool that you should use if you rerender manually from the command line (see [Rerendering feedstocks](updating_pkgs.md#dev-update-rerender)).

Smithy can be used beyond conda-forge's purposes. For example, it can be used to set up self-hosted Azure agents for non-conda-forge infrastructures.
(You could also consider using [Azure virtual machine scale set agents](https://docs.microsoft.com/en-us/azure/devops/pipelines/agents/scale-set-agents?view=azure-devops),
which could be less expensive to run than permanently active agents.)

#### Web services

The Heroku app providing the conda-forge web services lives in [conda-forge/conda-forge-webservices](https://github.com/conda-forge/conda-forge-webservices).
Please note that the code logic provided by the app is in the `Smithy` repository.

Bugs or suggestions regarding the service functionality should therefore be opened in `conda-forge/conda-smithy`'s [bug tracker](https://github.com/conda-forge/conda-smithy/issues).

#### conda-forge/conda-forge-bot

The code and logic behind [`conda-forge-bot`](#conda-forge-bot).

- 📜 Source at [`conda-forge/conda-forge-bot`](https://github.com/conda-forge/conda-forge-bot)
- 📖 [Documentation](https://github.com/conda-forge/conda-forge-bot/blob/main/README.md)

### Automated maintenance

These components perform actions in automated ways, either triggered by a specific event or continuously as part of a loop.

#### admin-migrations

- ⚙️ Deployed in [Github Actions via `conda-forge/admin-migrations`](https://github.com/conda-forge/admin-migrations)
- 🤖 Uses [`@conda-forge-curator`](https://github.com/apps/conda-forge-curator)
- 🔒 Has access to Github API, Anaconda.org (conda-forge and cf-staging), Circle, Travis, Azure

This repository hosts workflows that are running 24/7.
Its job is to procure an automation loop where some maintenance tasks are added.
Its main user is the core team.

#### admin-requests

- ⚙️ Deployed in [Github Actions via `conda-forge/admin-requests`](https://github.com/conda-forge/admin-requests)
- 🤖 Uses [`@conda-forge-curator`](https://github.com/apps/conda-forge-curator)
- 🔒 Has access to Github API, Anaconda.org (conda-forge and cf-staging), Circle, Travis, Azure

This repository hosts workflows that mainly run when triggered by a user-initiated action.
This is usually done via a PR that, once approved, is merged and triggers the requested action (mark a package as broken, archive a feedstock, etc).

It also does the job of creating new feedstocks for recipes that have been merged in [`conda-forge/staged-recipes`](#staged-recipes).
The [`create_feedstocks` workflow](https://github.com/conda-forge/admin-requests/blob/main/.github/workflows/create_feedstocks.yml) runs several times per hour to create the new feedstock repositories on the `conda-forge` organization.
The core logic is defined in the Python script [`.github/workflows/scripts/create_feedstocks.py`](https://github.com/conda-forge/admin-requests/blob/main/scripts/create_feedstocks.py).

#### conda-forge-bot

- ⚙️ Deployed in [`conda-forge/conda-forge-bot`](https://github.com/conda-forge/conda-forge-bot)
- ⛓ Needs [`conda-forge/conda-forge-bot`](https://github.com/conda-forge/conda-forge-bot), [`conda-forge/conda-forge-bot-data`](https://github.com/conda-forge/conda-forge-bot-data), [`conda-forge/conda-forge-pinning-feedstock`](https://github.com/conda-forge/conda-forge-pinning-feedstock)
- 🤖 Uses [`@regro-cf-autotick-bot`](https://github.com/regro-cf-autotick-bot)

:::note
The older repo [`regro/autotick-bot`](https://github.com/regro/autotick-bot) is no longer in use;
the bot now runs directly in `conda-forge/conda-forge-bot`.
:::

#### webservices

- ⚙️ Deployed in Heroku Dyno (`conda-forge.herokuapp.com`)
- ⛓ Needs [`conda-forge/conda-forge-webservices`](https://github.com/conda-forge/conda-forge-webservices)
- 🤖 Uses [`@conda-forge-webservices`](https://github.com/apps/conda-forge-webservices), [`@conda-forge-admin`](https://github.com/conda-forge-admin)
- 🔒 Has access to Github API, Anaconda.org (cf-staging and conda-forge), Heroku

This web application powers several services, like:

- the `@conda-forge-admin` bot and its `@conda-forge-admin, please ...` commands
- the `cf-staging` to `conda-forge` validation (plus copy)
- status monitoring

## Admin web services

conda-forge is running a webservice on Heroku called [conda-forge-webservices](https://github.com/conda-forge/conda-forge-webservices).

The following services are run by default on a feedstock:

- It will lint the recipes in the PRs and report back whether the recipe is in excellent condition or not.
- When maintainers are added to a recipe, each of the maintainers will be added to the team and given push access to the feedstock.

The webservice also listens to issues and PR comments, so that you can ask for the following services to be done:

### @conda-forge-admin, please rerender

Entering the above phrase in a PR of a feedstock will rerender the feedstock and push the changes to your PR.
Make sure to tick the `Allow edits from maintainers` button located at the bottom of the right side bar of
the PR. If you enter this phrase in the comment for an issue, the bot will create a new pull request, with the requested
re-rendering being completed.

### @conda-forge-admin, please add noarch: python

Entering the above phrase in a PR or an issue of a feedstock will add `noarch: python` to the build and rerender the feedstock
for you.

### @conda-forge-admin, please lint

Entering the above phrase in a PR of a feedstock will lint the PR again.

### @conda-forge-admin, please update team

Entering the above phrase in an issue will update the team for the feedstock. This is usually done automatically.

### @conda-forge-admin, please restart ci

Entering this command in the PR of a feedstock or staged-recipes will close and then open the PR, causing
all of the CI builds to restart.

### @conda-forge-admin, please ping team

Entering this command in the PR of a feedstock or staged-recipes will have the admin bot @-mention the team
associated with the repo. This command can be useful for people who are not yet members of conda-forge and
so cannot @-mention the `staged-recipes` team for PR reviews.

<a id="conda-forge-admin-please-ping-conda-forge"></a>

### @conda-forge-admin, please ping conda-forge/\<team>

Entering this command in the PR of a feedstock or staged-recipes will have the admin bot @-mention the respective team.
This command can be useful for people who are not yet members of conda-forge and
so cannot @-mention someone due to the general GitHub limitations.

### @conda-forge-admin, please rerun bot

Entering this command in a PR comment will add the `bot-rerun` label to that PR. This label will cause
the `auto-tick` bot that issues migration and version updates to close the current PR and reissue it.
Adding this label to non-bot issued PRs will have no effect.

### @conda-forge-admin, please add bot automerge

Entering this command in the title or comment of an issue will instruct the admin bot to
open a PR enabling the automatic merging of passing PRs from the `auto-tick`
bot. This functionality is currently experimental. You can find more details
[here](#automerge).
Please open issue on `conda-forge/conda-forge-bot` for any feedback, bugs, and/or questions!

### @conda-forge-admin, please remove bot automerge

Entering this command in the title or comment of an issue will instruct the admin bot to
open a PR to disable automerge, undoing the `please add bot automerge` command.

### @conda-forge-admin, please add user @username

Entering the above phrase in the title of an issue on a feedstock will make a PR
that adds the given user to the feedstock. A maintainer or member of `core` can then merge
this PR to add the user. Please do not modify this PR or adjust the commit message. This
PR is designed to skip building the package.

:::note[Using this command]

This is not the recommended way to start to help with a feedstock.
If you are interested in helping with a particular recipe, it is better to start by
submitting a PR with a new version or a fix. This way, you can get feedback on your
work and learn about some of the historical context of the feedstock.

Once you have established a working relationship with the maintainers, you can ask
them to add you to the feedstock team. They can then use this command
to add you to the team. There isn't any official requirement for how to add new
maintainers so it may take a while for consensus to be reached
on when to add new maintainers. Do not let this discourage you from contributing!

PRs are free to be opened by anyone!!! Thank you for your time and effort!!!

:::

### @conda-forge-admin, please remove user @username

Entering the above phrase in the title of an issue on a feedstock will make a PR
that _removes_ the given user from the feedstock. A maintainer or member of `core` can then merge
this PR to add the user. Please do not modify this PR or adjust the commit message. This
PR is designed to skip building the package.

### @conda-forge-admin, please update version

Entering the above phrase in the title of an issue on a feedstock will request the bot
to check if there are any new versions available. If there are, it will open a PR with
with the needed changes. Note that the bot might start by opening a PR with only partial
changes. The rest of the contents will be added in a subsequent commit after a few minutes.

### @conda-forge-admin, please convert to v1

Entering the above phrase in the title of an issue on a feedstock will request the admin bot
to convert the recipe to the v1 format using
[conda-recipe-manager](https://github.com/conda/conda-recipe-manager). You can also use this command
in a comment on a PR. If the conversion fails, the admin bot will post an error message with the
output of the conversion process. Note that the bot might start by opening a PR with only partial
changes. The rest of the contents will be added in a subsequent commit after a few minutes.

## CI build services

Here we describe common issues with the CI Services that conda-forge builds.

### Azure Pipelines

Azure is used to build packages for Windows (native x86_64), macOS (native x86_64), Linux (native x86_64, emulated ARMv8 and IBM Power8+).
The build queue on Azure is substantially larger than on all the other providers.
Azure builds have a maximum duration of 6 hours.

To see all builds on Azure, visit [https://dev.azure.com/conda-forge/feedstock-builds/\_build](https://dev.azure.com/conda-forge/feedstock-builds/_build).

#### Restarting builds

Presently Azure does not sync GitHub users. In order to restart a build you can restart it from the GitHub checks interface.
If that doesn't work, a close/open will kick off a new build. You can also use the web services command `@conda-forge-admin, please restart ci`.

### GitHub Actions

We use GitHub actions to rerender feedstocks and also run our pull request automerge service. We do not currently support builds on
GitHub Actions.

#### Webservices Background Jobs

The webservices Heroku app dispatches to GitHub Actions to run compute-intensive background jobs, including rerendering, version updates,
and automerge jobs. The GitHub actions runs happen on the [conda-forge-webservices repo](https://github.com/conda-forge/conda-forge-webservices).
These runs use the [webservices-dispatch-action Docker container](https://hub.docker.com/r/condaforge/webservices-dispatch-action) for some
operations. This container is tagged with the latest webservices version.

#### Automerge

Our automerge service runs via GitHub Actions in the [conda-forge-webservices repo](https://github.com/conda-forge/conda-forge-webservices).

PRs are automatically merged if they satisfy either of the two following sets of conditions:

1. are from the `regro-cf-autotick-bot`, have `[bot-automerge]` in the title, all statuses are passing, and the feedstock allows automerge
2. have the `automerge` label and all statuses are passing.

For PRs from the `regro-cf-autotick-bot`, it can be useful to remove the `[bot-automerge]` slug from the PR title if you are making
edits to the PR.

### Skipping CI builds

To skip a CI build for a given commit, put `[ci skip] ***NO_CI***` in the commit message.

:::note[Related links]

- **Abort builds with [skip ci]/etc** [(conda-forge.github.io/#629)](https://github.com/conda-forge/conda-forge.github.io/issues/629)
- **Skip CI requests** [(staged-recipes/#1148)](https://github.com/conda-forge/staged-recipes/issues/1148)

:::

### Third-party Use of Our CI Services

Due to its stature in the open-source community, conda-forge has enhanced access to certain CI services. This access is a community
resource entrusted to conda-forge for use in building packages. We thus cannot support third-party or "off-label" CI jobs in our
feedstocks on any of our CI services. If we find such use, we will politely ask the maintainers to rectify the situation. We may
take more serious actions, including archiving feedstocks or removing maintainers from the organization, if the situation cannot be rectified.

### External Runners (for GitHub Actions)

See [Self-hosted runners](/docs/how-to/advanced/self-hosted-runners/) and [Runners reference](/docs/reference/runners/).

## Compilers and Runtimes

conda-forge builds and maintains its own set of compilers for various languages
and/or systems (e.g., C, Fortran, C++, CUDA, etc.). These are used
in all of our CI builds to build essentially all artefacts published by conda-forge.

This compiler infrastructure has a critical role beyond building everything, which
is to ensure that packages stay compatible with each other. This is due to how compiled
packages have a so-called [Application Binary Interface](../glossary.md#abi)
(ABI), and how changes in the compiler infrastructure may break this ABI, leading
to crashes, miscalculations, etc. Generally speaking, using a consistent compiler
setup greatly reduces the risk of ABI breaks.

### Using compilers in feedstocks

There are two kinds of compiler-related packages in conda-forge: implementation packages
that install the compiler itself, and _activation_ packages that install scripts
that set the build environment to use the respective compiler by default. These
scripts set up a number of standard environment variables such as `CC`, and perform
setup actions for the common build systems such as CMake and Meson.

Recipes provide a `compiler` macro that is used to generate the correct dependency
on a compiler for the language specified. Compilers are always added to `build`
dependencies. For example, to depend on a C and C++ compilers, one would specify:

<RecipeTabs>

```recipe
requirements:
  build:
    - {{ compiler('c') }}
    - {{ compiler('cxx') }}
    - {{ stdlib('c') }}
```

```recipe
requirements:
  build:
    - ${{ compiler('c') }}
    - ${{ compiler('cxx') }}
    - ${{ stdlib('c') }}
```

</RecipeTabs>

The possible parameter values are listed in the [compilers supplied by conda-forge
](#compilers-supplied-by-conda-forge) section.

Almost always, in addition to a compiler of any programming language, you will
also need to depend on the C standard library via the `stdlib('c')` macro.
Note that currently this macro is only used to refer to the C standard library
and in the vast majority of cases all programming languages use that library,
therefore the macro is always used with the `'c'` parameter. For example,
a regular Rust package would use:

<RecipeTabs>

```recipe
requirements:
  build:
    - {{ compiler('rust') }}
    - {{ stdlib('c') }}
```

```recipe
requirements:
  build:
    - ${{ compiler('rust') }}
    - ${{ stdlib('c') }}
```

</RecipeTabs>

### Using non-default compilers in feedstocks

Our default compiler stack is made up very differently on each platform; each platform
has its own default compiler, with its own set of feedstocks that provide them.
However, it is often possible to use a different compiler if necessary. For example,
to use Clang 21 as the C and C++ compiler _on all platforms_ (and not just macOS), one would additionally specify
in `recipe/conda_build_config.yaml`:

```yaml title="recipe/conda_build_config.yaml"
c_compiler:
  - clang
c_compiler_version:
  - 21
cxx_compiler:
  - clangxx
cxx_compiler_version:
  - 21
```

Technically, the `compiler(...)` macro may accept arbitrary compiler names
as an argument. However, this only works as an incident of the current implementation.
Names other than the listed in this document or the
[conda-forge/conda-forge-pinning-feedstock](https://github.com/conda-forge/conda-forge-pinning-feedstock)
repository should not be used.

### Installing standard compilers manually

While the primary use case for conda-forge compiler packages is to provide build tools
for feedstocks, we try to keep the compilers in their various versions
working also for direct usage in conda environments. In fact, we also provide a few
convenience packages to install the respective compilers. For example, the [compilers feedstock
](https://github.com/conda-forge/compilers-feedstock) provides packages installing the same
C, C++ and Fortran compilers as normally used in build environments, along with their
activation scripts.

For example, to install these three compilers, one could invoke:

```bash
conda install compilers
```

Alternatively, specific compilers can be requested:

```bash
conda install cxx-compiler fortran-compiler
```

Other available convenience packages are listed in the [platform-default
compilers](#platform-default-compilers) list.

Please note that these packages must not be used in a feedstock; instead the macros
listed in [Using compilers in feedstocks](#using-compilers-in-feedstocks) must be used.

### MSVC compiler on Windows

conda-forge is not allowed to redistribute the MSVC compiler used on Windows,
and therefore only provides the activation scripts for an externally installed
compiler. Users who wish to compile code using MSVC, both for local use
and feedstock builds, have to install Microsoft Visual Studio manually.
For more information, see [How-to > Advanced > Building packages for Windows > Compiling native code on Windows with MSVC](/docs/how-to/advanced/windows/notes-on-native-code).

### Compilers supplied by conda-forge

#### Platform-default compilers

Currently conda-forge providers compilers for the following languages, that
can be specified as arguments to the `compiler(...)` macro:

- `c`, also provided by `c-compiler` package
- `cxx` (C++), also provided by `cxx-compiler`
- `fortran`, also provided by `fortran-compiler`
- `cuda`, also provided by `cuda-compiler`; see also [Guide for Maintainers of
  Recipes That Use CUDA](https://github.com/conda-forge/cuda-feedstock/blob/main/recipe/doc/recipe_guide.md)
- `rust`; see [Rust packages](/docs/maintainer/example_recipes/rust/)
- `go-cgo` and `go-nocgo`; see [Go packages](/docs/maintainer/example_recipes/go/)

The authoritative source of the current compilers and versions for various languages
and platforms is the [conda_build_config.yaml](https://github.com/conda-forge/conda-forge-pinning-feedstock/blob/main/recipe/conda_build_config.yaml) file
in the [conda-forge/conda-forge-pinning-feedstock](https://github.com/conda-forge/conda-forge-pinning-feedstock) repository
as described in [Globally pinned packages](pinning_deps.mdx#globally-pinned-packages).

The default C and C++ compilers are GCC on Linux, Clang on macOS and VS2022
on Windows. Clang can also be used as the compiler on Linux and Windows.
The default Fortran compiler is the GNU Fortran compiler on Linux and macOS,
and Flang on Windows.

Note that when used in conjunction with CUDA, the GCC version is restricted by the
maximum version supported by nvcc (which is also reflected in the global pinning).

#### clang vs. clang-cl on Windows

The `clang` compiler package installs two frontends, and conda-forge
provides separate activation scripts for Windows, for each of them. Therefore,
the following arguments can be used in `recipe/conda_build_config.yaml`:

- `clang` to use the `clang` frontend with GCC argument syntax
- `clang-cl` to use the `clang-cl` frontend with MSVC argument syntax

To use the `clang-cl` frontend on Windows, and the `clang` frontend on other
systems, the following dependencies can be used:

- `compiler('clang')` for the C compiler
- `compiler('clangxx')` for the C++ compiler

#### MinGW-based compiler stack for Windows

There exists an alternative, MinGW-based, compiler stack on Windows. To use it,
the following arguments can be passed to the `compiler(...)` macro:

- `m2w64_c` for the C compiler
- `m2w64_cxx` for the C++ compiler
- `m2w64_fortran` for the Fortran compiler

Along with these compilers, `stdlib('m2w64_c')` needs to be used.

These compilers correspond to the `gcc`, `gxx` and `gfortran` packages,
respectively. The `m2w64-*` compiler packages (with the exception of
`m2w64-sysroot`) are obsolete and no longer updated.

The MinGW C++ and Fortran compilers are not ABI-compatible with the default
stack, and therefore special care needs to be taken when performing
cross-library calls. The executables produced by them may link to the MinGW
compiler libraries, notably `libgcc`, `libwinpthread` and `libgomp`.

### Compiler ABI stability policy

Compilers generally strive to maintain ABI-compatibility across versions, meaning that
combining artefacts for the same target produced by different versions of the same
compiler will work together without issue. Due to the nature of the ABI (i.e. a vast
interface between software and hardware, with innumerable corner cases), it still
happens that unintentional changes for some specific aspect are introduced across
compiler versions, though in practice this does not lead to wide-spread issues.

In contrast, when compilers do intentionally change the ABI (as MSVC did with each
release before the `vc14` series currently covering VS2015-VS2022), _every_ compiled
package needs to be rebuilt for that new ABI, and cannot be mixed with builds for the
old ABI. While less likely nowadays, in principle it's also possible that a major
infrastructural overhaul in the compiler stack similarly forces a complete rebuild.

Such large-scale changes – requiring +/- all of conda-forge to be rebuilt – take a
lot of effort, though thankfully, in recent years such full rebuilds have not been
necessary and we managed to do less disruptive compiler upgrades.

However, large-scale ABI breaks remain a possibility (e.g. MSVC is planning a vNext
after `vc14`), and so we keep our policies for such a scenario in place.
While we do not have any formal promises of support for a generation of ABI-compatible
compilers, we have historically maintained them according to the following (non-binding)
principles.

- We provide no support of any kind in terms of the long-term stability/support of a given compiler generation.
- We upgrade them in an ad-hoc manner on a periodic basis as we have the time and energy to do so.
  Note that because of the way we enforce runtime constraints, these compiler upgrades will not break
  existing packages. However, if you are using the compilers outside of `conda`, then you may find issues.
- We generally provide notice in the form of an announcement when an ABI-incompatible compiler change is going to happen.
  Note that these changes take a bit of time to complete, so you will generally have time
  to prepare should you need to.
- Some of the criteria we think about when considering a compiler migration include:
  - the degree of disruption to the ecosystem,
  - the amount of work for the `core` team,
  - the amount of time it will cost our (volunteer) feedstock maintainers.

These compiler generations may or may not have some unofficial names for our
internal use (e.g. `comp7`). We note again that the existence of these names
does not imply any level of support or stability for the compilers
that form the given stack.

For the cases that do not require a complete rebuild of conda-forge (i.e. if the ABI
of a new compiler remains compatible, up to rare corner cases), we can just increase
the version in our global pinning, and it will slowly roll out to the ecosystem as
feedstocks get rerendered.

For such ABI-compatible upgrades, similar but looser principles apply:

- We provide no support of any kind in terms of the long-term availability of a given compiler version.
- We generally provide notice in the form of an announcement when a compiler is going to be upgraded.
- Without promising any timelines, our compilers on Linux and OSX are normally
  very recent; on Windows, we generally use the last supported VS version.

### More on compiler feedstocks

The compiler activation and implementation packages are built by two separate
feedstocks, with a few exceptions. The activation packages install scripts
into `/etc/conda/activate.d` and `/etc/conda/deactivate.d` directories, which
are invoked automatically when those environments are activated during the build. These
scripts are then used by the build tool to respectively prepare for building
with the given compiler, and clean up afterwards. The implementation packages
install the compilers themselves. More details can be found in the [Anaconda compiler tools
section of conda-build documentation](https://docs.conda.io/projects/conda-build/en/latest/resources/compiler-tools.html).

Due to historical
reasons (the way compilers are integrated with their OS, and the amount of
software written in them, etc.), the most impactful languages are C & C++ (though
Fortran is considered part of the default, not least because GCC compiles all three).

Linux (GCC):

- [C, C++, Fortran] Activation: https://github.com/conda-forge/ctng-compiler-activation-feedstock/
- [C, C++, Fortran] Implementation: https://github.com/conda-forge/ctng-compilers-feedstock

OSX (Clang + GNU Fortran):

- [C, C++] Activation: https://github.com/conda-forge/clang-compiler-activation-feedstock/
- [C, C++] Required feedstocks:
  [llvmdev](https://github.com/conda-forge/llvmdev-feedstock),
  [clangdev](https://github.com/conda-forge/clangdev-feedstock),
  [compiler-rt](https://github.com/conda-forge/compiler-rt-feedstock),
  [libcxx](https://github.com/conda-forge/libcxx-feedstock),
  [openmp](https://github.com/conda-forge/openmp-feedstock),
  [lld](https://github.com/conda-forge/lld-feedstock),
  [cctools](https://github.com/conda-forge/cctools-and-ld64-feedstock)
- [Fortran] Activation
  - as of GCC v15: https://github.com/conda-forge/ctng-compiler-activation-feedstock
  - until GCC v14: https://github.com/conda-forge/gfortran_osx-64-feedstock
- [Fortran] Implementation
  - as of GCC v15: https://github.com/conda-forge/ctng-compilers-feedstock
  - until GCC v14: https://github.com/conda-forge/gfortran_impl_osx-64-feedstock

Windows (MSVC + Flang):

- [C, C++] Activation: https://github.com/conda-forge/vc-feedstock
  (we cannot redistribute the actual MSVC compilers due to licensing constraints)
- [Fortran] Activation & Implementation: https://github.com/conda-forge/flang-feedstock

Additionally, there is a possibility to use `clang` as a compiler on Linux & Windows:

- Activation (Linux): https://github.com/conda-forge/ctng-compiler-activation-feedstock/
- Activation (Windows): https://github.com/conda-forge/clang-win-activation-feedstock/

Aside from the main C/C++/Fortran compilers, these are the feedstocks for the other compilers:

- [CUDA] [CUDA 12.0+](https://github.com/conda-forge/cuda-nvcc-feedstock) & [CUDA &lt;12](https://github.com/conda-forge/nvcc-feedstock) (legacy)
- [Rust] [Activation](https://github.com/conda-forge/rust-activation-feedstock)
  and [Implementation](https://github.com/conda-forge/rust-feedstock)
- [Go] [Activation](https://github.com/conda-forge/go-activation-feedstock)
  and [Implementation](https://github.com/conda-forge/go-feedstock)

### Conda-forge compiler maintenance

To upgrade the compiler version of our default compilers in the global pinning for
Linux or OSX, ensure that the respective above-mentioned feedstocks have been rebuilt
for the new major version, that all interrelated versions are lifted at the same time,
and obviously that the compilers work (e.g. by testing them on some feedstocks by
specifying the new version through the feedstock-local `conda_build_config.yaml`).
You should also check the compiler release notes for warnings about ABI incompatibilities,
and mention any such notices in the discussion about the upgrade.

For Windows, we stay on older compilers for longer, because using a newer toolchain
would force everyone wanting to locally develop with conda-forge artefacts to use
a toolchain that's at least as new. You can find more details about this topic in this
[issue about updating to the vc142 toolchain](https://github.com/conda-forge/conda-forge.github.io/issues/1732).

### CentOS `sysroot` for `linux-*` Platforms

We currently repackage the `sysroot` from the appropriate version of CentOS/AlmaLinux for use
with our compilers. These `sysroot` files are available in the `sysroot_linux-*` packages.
These packages have version numbers that match the version of `glibc` they package. These
versions are `2.17` for CentOS 7, `2.27` for AlmaLinux 8 and `2.34` for AlmaLinux 9.

## Output Validation and Feedstock Tokens

As of writing, `anaconda.org` does not support generating API tokens that are scoped
to allow uploads for some packages but not others. In order to secure feedstock uploads,
so that, e.g., the maintainers of the `numpy` feedstock cannot push a `python` package,
we use a package staging process and issue secret tokens, unique to each feedstock. This process
works as follows.

1. When a CI job on a feedstock is building packages to be uploaded to `anaconda.org`, it
   first uploads them to a staging channel, `cf-staging`.
2. Then the feedstock CI job makes an API call to our admin webservices server with its secret token
   and some information about the package it is trying to upload.
3. The webservices server validates the secret token, the integrity of the package, and
   that the package is allowed for the given feedstock. As a part of the validation process, the
   package is copied from `cf-staging` to a secured, intermediate staging channel, `cf-post-staging`.
   This step prevents changes to the package while it is being validated.
4. If all of the validation passes, the package is then copied from `cf-post-staging` to the
   `conda-forge` channel.

There are two scenarios we consider:

### Package validation failed for a new output name

New packages that are added to existing feedstocks are not registered automatically in order to prevent
typo squatting and other malicious activities. Package outputs are added during feedstock creation.
If you move a package from one feedstock to another, add an output package, or change the name of a package,
you will need to request that the new package name be added to your feedstock via the
[admin-requests repo](https://github.com/conda-forge/admin-requests?tab=readme-ov-file#add-a-package-output-to-a-feedstock).

In rare cases, the package name may change regularly in a well-defined way (e.g., `libllvm18`, `libllvm19`, etc.).
In this case, you can use our [admin-requests repo](https://github.com/conda-forge/admin-requests?tab=readme-ov-file#add-a-package-output-to-a-feedstock)
to add a glob pattern that matches the new package name pattern. We use the Python `fnmatch` module syntax.
Output packages that match these patterns will be automatically registered for your feedstock.

### Package validation failed for an existing output name

This may happen when the feedstock has not been built and uploaded in a long time,
so its output was never registered. Feedstocks created before output registration existed only
get their outputs registered on their next successful upload, so a build fails validation until
the mapping is added. Register the output via the
[admin-requests repo](https://github.com/conda-forge/admin-requests?tab=readme-ov-file#add-a-package-output-to-a-feedstock).

If the output is already registered and you are still having trouble with uploads, note that we
attempt to report errors in this process to users via comments on commits/issues in the feedstocks,
and sometimes these reports fail. In that case, make sure to check/try the following things:

- Ensure that `conda_forge_output_validation: true` is set in your `conda-forge.yml`.
- Retry the package build and upload by pushing an empty commit to the feedstock.
- Rerender the feedstock in a PR from a fork of the feedstock and merge.
- Request a feedstock token reset via our
  [admin-requests repo](https://github.com/conda-forge/admin-requests?tab=readme-ov-file#reset-your-feedstock-token).
  A token reset only re-authenticates uploads; it does not register outputs.

## Stages of package building and involved infrastructure

Packages in conda-forge are almost[^manual-builds] always built through CI.
However, when a new package enters conda-forge for the first time, it does so via a pull request in the [`staged-recipes` repository](#staged-recipes), whereas every new build of the package after that is built in its repository, the so-called feedstock.
Both places use slightly different CI setups and interact with the infrastructure accordingly.
Hence, we first describe the interaction at the start of a new package and then for existing packages in their respective feedstocks.

[^manual-builds]:
    Very few packages cannot be built through CI due to special resource
    requirements. These packages may be built and uploaded manually following the rules
    laid out in [CFEP-3](https://github.com/conda-forge/cfep/blob/main/cfep-03.md).

### Initial submission to staged-recipes

The `conda-forge/staged-recipes` repository uses several pieces of infrastructure.

On pull requests:

- Package building pipelines. These are slightly different than the ones running in feedstocks (they are not automatically generated by `conda-smithy`, but they do use the same underlying components).
- The linter is provided by `conda-smithy recipe-lint`, run by `@conda-forge-admin`.
- Auto-labeling logic, run by Github Actions workflows.

Authenticated services involved:

- Github, with permissions for:
  - PR labeling
- Azure Pipelines

The conversion of new recipes in `staged-recipes` to their respective feedstocks
happens in a cron job run by `admin-requests`. For more details see [admin-requests](#admin-requests).
As part of the feedstock creation, the new feedstock receives a webhook connecting it with the [webservices](#admin-web-services).

### Feedstock changes

A feedstock can receive changes for several reasons.

Pushes to `main` or other branches:

- The automated initialization commits following approval in `staged-recipes`.
  These are generated by `conda-smithy` and pushed by the automation in `admin-requests`.
- Automated maintenance commits triggered from `admin-migrations`.
- Rerender requests are handled by instances of `conda-forge/webservices-dispatch-action` and triggered by the [webservices](#admin-web-services).

Automatic pull requests can be opened by...

- `@conda-forge-admin`, responding to some issues with titles like `@conda-forge-admin, please...`.
- `@regro-cf-autotick-bot`, handling migrations and new versions being available.

...and closed by:

- `conda-forge/automerge-action`, if labeled accordingly.

On an open pull request:

- The building pipelines (more [below](#package-building)).
- The linter is provided by `conda-smithy recipe-lint`, run by `@conda-forge-admin`.
- The `@conda-forge-admin, please...` command comments, answered by `@conda-forge-admin`.

On issues:

- `@conda-forge-admin, please...` command issues, handled by `@conda-forge-admin`.

### Package building {#package-building}

The pipelines that build conda packages are used for both pull requests and push events in `main` and other branches.
The only difference is that the packages built during a pull request are not uploaded to the staging channel.
Maintaining these up-to-date across all feedstocks involves several repositories:

- `conda-smithy` is in charge of generating the CI pipelines themselves, together with the supporting scripts and configuration files.
  These pipelines and scripts can rely on code and data defined in the repositories below.
- `conda-forge-ci-setup-feedstock` provides the code needed to prepare and homogenize the CI runners across providers.
  It also does some checks before the artifacts are uploaded to `cf-staging`.
- `conda-forge-pinning-feedstock` defines which versions are supported for a number of runtimes and libraries, as well as the compilers used for certain languages and platforms.
- `docker-images` builds the standardized container images for Linux runners.
  This repository has additional authentication needs for Docker Hub, Quay.io.

The pipelines can run on several CI providers supported by `conda-smithy`, including:

- Azure DevOps Pipelines
- Github-hosted Actions runners
- Self-hosted Github Actions runners

Registration of hooks and triggers is also done by the `conda-smithy` app.

:::tip
`conda-smithy` supports more CI providers.
Check [its repository](https://github.com/conda-forge/conda-smithy) for more details.
:::

Authenticated services involved:

- Anaconda.org uploads to `cf-staging`

### Package validation and publication

Once built on `main` (or other branches), the conda packages are uploaded to an intermediary channel named `cf-staging`.
The CI job then makes a copy request to the webservices with the feedstock token and other metadata about the package.
From there, our webservices (`conda-forge/conda-forge-webservices`) does the following:

1. The webservices validates the package and copy request by
   - using the feedstock token to authenticate the copy request by the CI job
   - checking that the hash sum of the package on `cf-staging` from the `anaconda.org` API
     is the same as the value sent in the copy request by the CI job
   - checking that the feedstock is allowed to push the package using the
     `conda-forge/feedstock-outputs` repo
2. If all three checks pass, the webservices copies the package to a secured, intermediate
   staging channel, `cf-post-staging`, in order to ensure the package is not changed further during validation.
3. The webservices repeats the check of the package hash sum on `cf-post-staging` to ensure no changes were made
   during the initial validation step.
4. If the second hash sum check passes, the webservices copies the package to the `conda-forge` channel.

Authenticated services involved:

- Anaconda.org uploads to `conda-forge`, `cf-post-staging`, and `cf-staging`
- The `conda-forge-webservices` app deployment itself (currently at Heroku)

### Post-publication

Once uploaded to anaconda.org/conda-forge, packages are not immediately available to CLI clients.
They have to be replicated in the Content Distribution Network (CDN).
This step should ideally take around 15 minutes. In some circumstances, longer delays are possible. Check [conda-forge.org/status](https://conda-forge.org/status) in case of doubt.

After CDN replication, most packages available on anaconda.org/conda-forge won't suffer any further modifications.
However, in some cases, maintainers might need to perform some actions on the published packages:

- Patching their repodata
- Marking them as broken

#### Repodata patch

The metadata for `conda` packages is initially contained in each package archive (under `info/`).
`conda index` iterates over the published `conda` packages, extracts the metadata and consolidates all the found JSON blobs into a single JSON file: `repodata.json`.
This is where the hashes and file sizes are added too.
This is the metadata file that the CLI clients download initially to _solve_ the environment.

Since the metadata is external to the package files, some details can be modified without rebuilding packages, which simplifies some maintenance tasks notably.

Repodata patches are created in `conda-forge/conda-forge-repodata-patches-feedstock`, which generates (and uploads) a regular `conda` package as a result:
[`conda-forge-repodata-patches`](https://anaconda.org/conda-forge/conda-forge-repodata-patches/files).
Each of these timestamped packages contains the patch instructions for each channel subdir on conda-forge.
The Anaconda infrastructure takes the JSON files from these packages and applies them on top of the vanilla `repodata.json` (which remains available for download as `repodata_from_packages.json`).

Since `conda-forge-repodata-patches-feedstock` operates as a regular feedstock for package publication, there are no further infrastructural details to cover.

#### Mark a package as broken

Sometimes a package is faulty in ways that a repodata patch cannot amend (e.g. bad binary).
In these cases, conda-forge does not remove packages from Anaconda.org.
Instead, it marks them with the `broken` label, which has a special meaning:
packages labeled as such will be removed from the repodata via automated patches.
This action is reversible and doesn't change the direct URL of the artifact, which
can always be downloaded from e.g. a lockfile.

The main repository handling this is `conda-forge/admin-requests`, which features different
Github Actions workflows running every 15 minutes.

For this task, the Github Action workflow needs access to:

- Anaconda.org, to add (or remove) labels
- Github, to modify and commit the input files after success

## Inventory of services & providers

### Github resources

In addition to the thousands of repositories, conda-forge uses several other Github services.

#### Organizations

- [`conda-forge`](https://github.com/conda-forge): the main organization
- [`regro`](https://github.com/regro): hosts the `conda-forge-bot` machinery
- [`channel-mirrors`](https://github.com/channel-mirrors): OCI mirror of the conda-forge channel

:::info
These organizations exist but they are not in active use anymore:

- [`conda-forge-abandoned`](https://github.com/conda-forge-abandoned)
- [`conda-forge-woodpecker-admins`](https://github.com/conda-forge-woodpecker-admins)

:::

#### Teams

The `conda-forge` Github organization has thousands of teams.
Most of them are associated with a feedstock, but there are a few special ones that are not!

<!-- TODO: The following list is prone to getting out of date. We should generate it automatically. -->

- [`Core`](https://github.com/orgs/conda-forge/teams/Core)
- [`staged-recipes`](https://github.com/orgs/conda-forge/teams/staged-recipes)
- [`help-c-cpp`](https://github.com/orgs/conda-forge/teams/help-c-cpp)
- [`help-cdts`](https://github.com/orgs/conda-forge/teams/help-cdts)
- [`help-go`](https://github.com/orgs/conda-forge/teams/help-go)
- [`help-java`](https://github.com/orgs/conda-forge/teams/help-java)
- [`help-julia`](https://github.com/orgs/conda-forge/teams/help-julia)
- [`help-nodejs`](https://github.com/orgs/conda-forge/teams/help-nodejs)
- [`help-osx-arm64`](https://github.com/orgs/conda-forge/teams/help-osx-arm64)
- [`help-perl`](https://github.com/orgs/conda-forge/teams/help-perl)
- [`help-ppc64le`](https://github.com/orgs/conda-forge/teams/help-ppc64le)
- [`help-pypy`](https://github.com/orgs/conda-forge/teams/help-pypy)
- [`help-python`](https://github.com/orgs/conda-forge/teams/help-python)
- [`help-python-c`](https://github.com/orgs/conda-forge/teams/help-python-c)
- [`help-r`](https://github.com/orgs/conda-forge/teams/help-r)
- [`help-ruby`](https://github.com/orgs/conda-forge/teams/help-ruby)
- [`help-rust`](https://github.com/orgs/conda-forge/teams/help-rust)
- [`miniforge`](https://github.com/orgs/conda-forge/teams/miniforge)
- [`all-members`](https://github.com/orgs/conda-forge/teams/all-members)
- [`bot`](https://github.com/orgs/conda-forge/teams/bot)

#### Configuration

- [`conda-forge/.github`](https://github.com/conda-forge/.github): Organization-wide configuration, profile information, etc.
- [`conda-forge/.cirun`](https://github.com/conda-forge/.cirun): Organization-wide configuration for special ci runners (e.g. GPU), c.f. [Cirun](#cirun).

#### Bot accounts

- [`conda-forge-admin`](https://github.com/conda-forge-admin)
- [`conda-forge-daemon`](https://github.com/conda-forge-daemon)
- [`regro-cf-autotick-bot`](https://github.com/regro-cf-autotick-bot)

:::info
These accounts exist but are not in active usage anymore:

- [`conda-forge-bot`](https://github.com/conda-forge-bot)
- [`conda-forge-coordinator`](https://github.com/conda-forge-coordinator)
- [`conda-forge-drone-ci`](https://github.com/conda-forge-drone-ci)
- [`conda-forge-linter`](https://github.com/conda-forge-linter)
- [`conda-forge-manager`](https://github.com/conda-forge-manager)
- [`conda-forge-status`](https://github.com/conda-forge-status)

:::

#### Apps

- `conda-forge-curator`
- `conda-forge-webservices`

:::info
These apps exist but are not in active usage anymore:

- `conda-forge drone instance`

:::

#### Workflows

- [`beckermr/turnstyle-python`](https://github.com/beckermr/turnstyle-python): Prevents multiple CI jobs from running in parallel to avoid race conditions.
- [`conda-forge/automerge-action`](https://github.com/conda-forge/automerge-action)
- [`conda-forge/webservices-dispatch-action`](https://github.com/conda-forge/webservices-dispatch-action)

### Continuous integration

:::tip See also
Refer to the [`conda-forge.yml` documentation](/docs/maintainer/conda_forge_yml/) to learn how to configure your CI providers.
:::

#### Azure Pipelines

- 🌐 https://dev.azure.com/conda-forge/feedstock-builds/_build
- 📍 Available on all feedstocks
- 🛠 Provides [Microsoft-hosted runners](https://learn.microsoft.com/en-us/azure/devops/pipelines/agents/hosted?view=azure-devops&tabs=yaml) (x64 Linux, macOS and Windows)
- 🔒 Needs access to Anaconda.org (cf-staging)

conda-forge benefits from the generously offered Microsoft-hosted runners.

#### Cirun

- 🌐 https://cirun.io
- 📍 Available on selected feedstocks only
- 🛠 Provides several architectures (depending on feedstock configuration)
- 🔒 Needs access to Anaconda.org (cf-staging) and the configured backend

Configured with `@conda-forge-daemon`.

Organization-wide configuration can be found in the [`.cirun` repository](https://github.com/conda-forge/.cirun).

:::info
This allows, for example, access to custom runners for Github Actions.
:::

#### Github Actions

- 🌐 https://github.com/features/actions
- 📍 Not available in feedstocks (only admin tasks)
- 🛠 Provides [GitHub-hosted runners](https://docs.github.com/en/actions/using-github-hosted-runners/about-github-hosted-runners) (x64 Linux, macOS and Windows)
- 🔒 Has access to Github API

#### Retired services

- [Travis CI](https://app.travis-ci.com/github/conda-forge)
- [AppVeyor](https://ci.appveyor.com/account/conda-forge/projects)
- Circle CI
- Drone.io

### Delivery and distribution

#### Anaconda.org

- 🌐 Channels/organizations: [`cf-staging`](https://anaconda.org/cf-staging/dashboard), [`conda-forge`](https://anaconda.org/conda-forge/dashboard)
- ⛓ Used by feedstocks

#### Docker Hub

- 🌐 https://hub.docker.com/u/condaforge/
- ⛓ Used by [`conda-forge/docker-images`](#docker-images), [`conda-forge/miniforge-images`](https://github.com/conda-forge/miniforge-images)

#### Github Packages

- 🌐 https://github.com/orgs/channel-mirrors/packages
- ⛓ Used by [`channel-mirrors/conda-oci-mirror`](https://github.com/channel-mirrors/conda-oci-mirror)

#### Github Releases

- 🌐 https://github.com/conda-forge/miniforge/releases
- ⛓ Used by [`conda-forge/miniforge`](https://github.com/conda-forge/miniforge)

#### Quay

- 🌐 https://quay.io/organization/condaforge
- ⛓ Used by [`conda-forge/docker-images`](#docker-images)

### Servers

#### Heroku

- 🌐 https://conda-forge.herokuapp.com/status-monitor
- ⛓ Used by [`webservices`](#webservices)

### Other services

- Google: `condaforge@gmail.com`
- Google Groups: [conda-forge](https://groups.google.com/g/conda-forge) (retired)
- HackMD: [conda-forge](https://hackmd.io/team/conda-forge)
- Open Collective: [conda-forge](https://opencollective.com/conda-forge/)
- Namecheap (conda-forge.org)
- Twitter: [@condaforge](https://twitter.com/condaforge)
- YouTube: [Conda Forge](https://www.youtube.com/@condaforge3075)