A new conda-forge package starts as a recipe submitted by pull request to the staged-recipes repository. The conda-forge team reviews it, and once merged it becomes a feedstock repository with its own maintainers. Contributing a package makes you its maintainer, responsible for updates.
The three steps
conda-forge's documentation describes the contribution process in three steps.
- Staging. Add the package's recipe and license to staged-recipes and open a pull request.
- Post staging. After the pull request merges, the project's post staging process takes over and a feedstock and team are created.
- Maintaining. The contributor becomes the maintainer of that package.
The infrastructure page describes staged-recipes as the gateway to conda-forge, where submitted recipes, once reviewed and accepted, generate a new feedstock and team.
What a recipe must contain
The guide for adding packages lists practical requirements that also work as integrity controls.
- The source must be downloadable as a single archive, such as a tar.gz.
- The recipe needs a SHA256 hash of that archive. You can compute it with openssl, or copy it from the package page on PyPI.
- A test section must be filled in. The simplest test imports the top-level package or module.
- The license must be provided with the recipe.
- Generic instruction comments should be removed from the final recipe.
The guide mentions grayskull as a way to generate a recipe, and notes the output may need review and editing. It also says that if you are unsure about details, you should open the pull request anyway, and the team will review it and help.
What this tells you as a user
| Control | Value for a consumer |
|---|---|
| Recipe review by a team | A second pair of eyes on how the package is built |
| SHA256 of the source archive | Detects a changed upstream archive |
| Required test | Basic proof the package imports |
| Named maintainers | Someone accountable for updates |
None of that is a code audit of the upstream project. A hash proves the archive matches what the recipe author saw, not that the code is benign.
Practical advice for research environments
- Prefer one primary channel and keep the channel list explicit in your environment file. See is it safe to mix conda channels.
- Record exact builds in a lockfile. See how to create a multi-platform conda lockfile.
- Scan the environment. See scanning conda and pip environments.
Try it yourself
Click through it at your own pace, or open it full screen. Look at the inventory of components, which is the list you would compare against what your environment resolved.
Quick check
Who maintains a conda-forge package after it is accepted?
The contributor who submitted it becomes its maintainer, per the conda-forge documentation, and a feedstock and team are created for it.
Does the SHA256 in a recipe prove the code is safe?
No. It shows the source archive matches the one referenced in the recipe. It says nothing about whether the upstream code is free of flaws.
Safeguard's SBOM and dependency scanning can inventory an environment, and a free scan is available.
Sources
Last reviewed: 19 October 2026.
