Conda Channel Standards

RepoForge.io Conda channels work with conda, mamba, micromamba and pixi / rattler without extra configuration.

Conda has no single formal channel standard. repodata.json is defined by its reference implementation, conda-index, and conda's documentation, with later additions in Conda Enhancement Proposals (CEPs). Channels follow those, plus the HTTP specifications below. Behavior that clients depend on but no specification defines is listed separately, under ecosystem conventions.

Repository Format

Standard	Specification
repodata.json	Conda channel structure and repodata and conda-index
Package formats	Conda package specification
CEP-17	python_site_packages_path in info/index.json

• .tar.bz2 packages are listed under packages and .conda packages under packages.conda, and repodata_version is 1, so clients can prefer .conda and de-duplicate builds that exist in both formats.
• Each repodata record is a copy of the package's info/index.json, including constrains and track_features. Fields that RepoForge.io doesn't model itself, such as python_site_packages_path from CEP-17, are passed through.
• timestamp is optional, as in info/index.json. Packages without one are accepted, and it's left out of their record.
• Packages are served from per-platform subdirectories, including noarch.
• Uploads must be named {name}-{version}-{build}.conda or .tar.bz2, matching the package's info/index.json. Other extensions and mismatched names are rejected with 400 Bad Request.

HTTP

Standard	Specification
RFC 9110	HTTP Semantics
RFC 9111	HTTP Caching
RFC 7617	The "Basic" HTTP Authentication Scheme
RFC 6750	The OAuth 2.0 Bearer Token Usage

• HEAD works on package downloads and on repodata.json.
• repodata.json carries ETag, Last-Modified and Cache-Control: max-age, and conditional requests get 304 Not Modified, so clients only download repodata when it changes.
• Authenticate with an access token as the password of HTTP Basic auth, or send it as Authorization: Bearer <token>, as rattler and pixi do.

Ecosystem Conventions

These aren't in a specification. They match anaconda.org and the way conda clients behave:

• repodata.json.zst. A zstd-compressed copy of each repodata.json is served with the same authentication and caching headers. conda 23 and later request it first.
• /t/<token>/ channel URLs. A token can go in the channel URL, as on anaconda.org, for example https://api.repoforge.io/conda/t/<token>/unique-hash-id/my-channel. This lets you use conda config --add channels and pixi auth login --conda-token without a username.
• No overwriting. Uploading a filename that already exists in the channel and platform returns 409 Conflict, as on anaconda.org. Clients check downloads against the sha256 in their cached repodata, so a replaced file would fail to install.
• Private channels protect repodata. The repodata.json of a private channel needs credentials with the Conda - Read only role (or package level permission), so package names, versions and dependencies aren't public. Public channels stay anonymous.
• Channel names. Names can contain letters, numbers, ., _ and -, and can't start with ..

For uploading and installing, see Using Conda with RepoForge.io.