2026 Remote Mac CI Matrix: Conda, mamba & micromamba

Pick one primary installer per pipeline and document why. Mixing solves without isolating CONDA_PKGS_DIRS creates subtle binary mixes when jobs overlap on the same host.

Cross-border CI rarely needs “more bandwidth”; it needs predictable URLs that security teams already allow. Store a committed .condarc beside environment.yml with channel_priority: strict, an ordered channels: list (typically conda-forge first), and optional custom_channels / channel_alias entries that point to your org mirror instead of the public defaults.

Environment variables that belong in CI logs (never secrets): CONDA_SUBDIR=osx-arm64 pins the platform label for Apple Silicon; pair it with explicit macOS SDK expectations in your build matrix. If you must remap hosts, export CONDA_CHANNEL_ALIAS=https://mirror.example.com/ only when your mirror preserves path layout compatible with conda’s channel URL rules—validate with a dry-run against both upstream and mirror in a staging runner.

Keep defaults channels out of the list unless compliance requires them; mixing defaults and conda-forge without a documented policy is a frequent source of “works on my laptop” solver differences. When you introduce a new mirror, schedule a one-time repodata comparison (package count and priority) so product security can sign off before production CI depends on it.

export CONDA_SUBDIR="osx-arm64"
export CONDA_ALWAYS_YES="1"
export CONDA_CHANNEL_PRIORITY="true"
# Job-local package cache on NVMe — change path per tenant
export CONDA_PKGS_DIRS="${CI_PROJECT_DIR}/.conda/pkgs"
mkdir -p "${CONDA_PKGS_DIRS}"

# Example: micromamba create from committed env spec (adjust binary path)
./bin/micromamba create -y -p "${CI_PROJECT_DIR}/.conda/env" \
  -f environment.yml

On shared remote Mac hosts, the enemy is often concurrent disk I/O, not CPU. Cap parallelism before you chase faster solves: start with modest download concurrency and limit extract threads so two pipelines cannot each unpack large scientific stacks into the same NVMe volume at once.

Representative knobs include MAMBA_EXTRACT_THREADS (keep small on congested pools), solver threads where exposed by your build, and job-level exclusivity rules (only one heavy conda job per machine) enforced by your orchestrator. Pair these limits with a per-job CONDA_PKGS_DIRS so partial downloads never poison a warm shared cache owned by another team.

If you also compile large C++ extensions inside the same job, separate “solve and link” from “test” stages in your pipeline so Link-Time Optimization spikes do not overlap with another pipeline’s package extraction burst on the same host.

export MAMBA_EXTRACT_THREADS="2"
# Optional: reduce noisy progress when collecting logs
export MAMBA_NO_BANNER="1"

# mamba / micromamba style install with explicit channel file
mamba env update -n ci -f environment.yml --prune

Wrap environment creation in a shell loop that retries transient HTTP 502/504, TLS resets, and stalled downloads, using sleeps such as 2s / 4s / 8s with a hard attempt cap. When the solver succeeds but extract fails with checksum errors, delete only the affected package directory under CONDA_PKGS_DIRS rather than wiping the entire cache—other jobs may still benefit from unrelated artifacts.

If the same package version fails across regions, treat it as a mirror data issue, not a retry problem: open a ticket with whoever operates your pull-through cache and keep a documented fallback channel order for emergencies.

set -euo pipefail
attempt=1
max_attempts=4
until [ "$attempt" -gt "$max_attempts" ]; do
  echo "conda solve/install attempt ${attempt}/${max_attempts}"
  if micromamba create -y -p ./.venv -f environment.yml; then
    break
  fi
  sleep $((2 ** attempt))
  attempt=$((attempt + 1))
done
[ "$attempt" -le "$max_attempts" ] || exit 1

Treat environment.yml as the human-edited contract and a conda-lock output as the machine truth. In CI, regenerate or verify locks on a protected branch, commit conda-lock.yml (or platform-specific lock filenames your standard defines), and add a gate that runs conda-lock --check or an equivalent diff against the pinned graph.

Never rely on “export from a developer laptop” as the source of truth: exports include implicit channel state. Instead, fail builds when conda env export from the solved CI environment differs from the committed lock except for benign fields you whitelist (name, prefix). Document the exact export flags your team allows.

Prefer explicit version pins or conda-lock’s category: dev splits over loose >= ranges in environment.yml when reproducibility is mandatory; loose ranges are fine for research sandboxes but hostile to deterministic CI.

# Example: generate platform lockfile(s) from the spec (trusted runner)
conda-lock -f environment.yml -p osx-arm64

# Later on the remote Mac job: create strictly from the generated lock
# (filename varies by conda-lock settings; use the osx-arm64 artifact you committed)
micromamba create -y -p ./.venv -f conda-osx-arm64.lock

1. Committed .condarc lists channels in priority order and matches security-approved mirrors.
2. CONDA_SUBDIR matches the runner CPU architecture and macOS baseline in the matrix.
3. CONDA_PKGS_DIRS points to a job-scoped directory with enough free APFS space.
4. Parallelism caps (extract threads, concurrent heavy env jobs per host) are documented and enforced.
5. Install scripts use bounded retries and targeted cache cleanup on checksum failures.
6. conda-lock outputs are committed and checked on pull requests that touch dependencies.
7. Export-based drift checks fail CI when the solved graph changes without a lock update.

Is this guide a substitute for the Python uv / PyPI matrix? No. That article covers wheels and index proxies; here the artifact model is conda packages and repodata. Choose per stack—many teams use both, but different lockfiles.

Should we mirror every channel? Mirror only what you consume regularly; every extra endpoint is another TLS inspection and cache invalidation surface.