A conda-forge package is built from a feedstock, a repository that holds one recipe. Changes arrive mostly as pull requests, builds run on public CI, and artifacts pass validation before upload. That gives a visible process. It does not prove the upstream source is safe.
Definition
The conda-forge documentation defines a feedstock as the home of one recipe. It may produce more than one conda artifact in the case of a multi output recipe. Most events in the life of a recipe take place there.
What happens on a build
According to the feedstock documentation, the sequence runs like this:
- A build is triggered, either in a pull request or by a commit to a branch of the feedstock.
- For Linux and noarch packages the build runs in a Docker container on the CI. On macOS and Windows it uses the CI runner image.
- Local validation checks that the artifacts are permissible for this feedstock by consulting a feedstock outputs repository.
- Upload happens only if local validation succeeded, and only under certain conditions, for example commits to main and not pull requests.
- Server side validation repeats the check inside the distribution infrastructure, to guard against intentional or unintentional interference at the feedstock level.
Who can change a recipe
Almost all changes go through pull requests, whether made by a maintainer or by conda-forge automation. Any GitHub user can open a pull request by forking the feedstock. The feedstock maintainers or the core team review and merge it. A linter checks the recipe, and the documentation says linter failures must not be ignored without explicit core approval.
A version update, at a minimum, changes the version, the download URL and the hash of the upstream source archive.
One warning in the text is worth repeating. Any commit on any branch of the feedstock can lead to a package being built and published, so development branches must not be added to the feedstock. Work happens in forks.
What this means for your review
| Question | What the process tells you |
|---|---|
| Is the build recipe public and reviewable? | Yes, it lives in the feedstock |
| Is the upstream source hash recorded? | Yes, in the recipe |
| Was the source itself safe? | The process does not say |
| Is a maintainer account secure? | Not shown by the build process |
| Will a flagged package disappear quickly? | Not covered here, check channel practice |
So treat a conda-forge package as you would any package. Pin it, scan it, and watch advisories for it. The visible build chain is an advantage when you do investigate, because you can read the recipe and its history.
Practical steps
- For critical packages, open the feedstock and read recent merged pull requests.
- Note who the maintainers are and how many there are.
- Pin versions and, if you can, hashes in an explicit spec.
- Subscribe to advisories for the upstream project, since the feedstock follows upstream releases.
Safeguard's dependency scanning and zero-day discovery help you see when a pinned package becomes a problem. Try the free scan at gold.safeguard.sh/scan.
Quick check
Does conda-forge build packages on a maintainer laptop?
According to its documentation, builds run on CI, using a Docker container for Linux and noarch packages.
Does a feedstock guarantee the upstream code is safe?
No. It records and validates the build, not the safety of the source.
Sources
- The feedstock, conda-forge documentation, fetched 19 October 2026.
Last reviewed: 19 October 2026.
