Conda env export includes prefix path and platform-specific build strings

Direct answer

conda env export produces a local environment snapshot. It embeds the absolute prefix path (e.g., /home/user/miniconda3/envs/myenv) and platform-specific build strings (e.g., numpy-1.24.3-py39h5a1b2c3_0) that encode OS, architecture, and compiler details. Because channel configuration and priority are not fully captured, resolution can differ across machines even with the same YAML. Therefore, the exported file should not be used as a cross-platform production deployment artifact without transformation.

Why the exported YAML is not portable

• Prefix path – machine-specific and must be removed or replaced on the target system.
• Build strings – tied to the original platform; packages with those exact build hashes may not exist or be compatible on another OS/architecture.
• Channel drift – channel order, custom channels, and channel_priority are not locked; the same spec can resolve to different package sets over time or on different hosts.
• --from-history limitation – exports only explicitly requested packages, omitting transitive dependencies. Recreated environments often miss required runtime libraries, breaking applications.

Recommended production workflow

1. Maintain a human-readable environment.yml with version-pinned dependencies but without build strings (e.g., numpy=1.24.3).
2. Use conda-lock to generate platform-specific lock files:

   conda-lock lock -f environment.yml --kind=explicit --platform linux-64 --platform osx-64 --platform win-64

   This produces immutable conda-linux-64.lock, conda-osx-64.lock, etc., that record exact package URLs and hashes.
3. Deploy the appropriate lock file per target platform:

   conda create -n prod --file conda-linux-64.lock

4. Optionally mirror channels or use conda-lock with --kind=explicit to create fully self-contained artifacts immune to channel drift.

Quick verification you can run locally

• Run conda env export and inspect the YAML for prefix: and build-string suffixes (e.g., py39h123456_0).
• Compare conda env export vs conda env export --from-history to see missing transitive dependencies.
• Test conda env create -f exported.yml in a Docker container for a different OS/architecture to observe resolution failures.
• Generate lock files with conda-lock and verify they install cleanly on each target platform.

One diagnostic detail that would change the recommendation

If your production targets a single, identical OS/architecture (e.g., only Linux x86_64) and you control the channel configuration on all hosts, you can strip the prefix: line and use the exported YAML directly—though conda-lock remains safer for long-term reproducibility. For mixed platforms, lock files are mandatory.