If you need the same environment on more than one machine or date, yes, you want a lock file. An environment.yml states desired packages, and the solver may choose differently later. The conda-lock tool records the exact solution for each platform you target, including a pip section.
Definition
The conda-lock project describes itself as a lightweight library that generates fully reproducible lock files for conda environments. It does this by performing a conda solve for each platform you want. Installing from the generated file means the conda solver is not invoked, because the answer is already written down.
The project explains why: environment.yml files are useful for defining desired environments, but sometimes you need to exactly reproduce one by downloading the packages needed, for example in a gitops style setup that provisions environments in several places.
Basic usage
The project readme shows this flow:
conda-lock -f environment.yml -p osx-64 -p linux-64
conda-lock install -n my-locked-env
It writes conda-lock.yml by default. If a lock file already exists, it is used as a constraint when regenerating, so you can add a package while keeping the rest locked. There is also an option to render single platform files for use with conda create.
What it adds
- One lock file for several platforms, instead of separate files by hand.
- A way to update one package at a time, such as an update flag followed by a package name, while the rest stay put.
- Locking for the pip section of environment.yml, using a vendored copy of a dependency solver.
- Categories, so production and development dependencies can sit in separate files.
What it does not do
A lock file fixes versions. It does not check them for vulnerabilities, and a locked vulnerable version stays vulnerable. It also adds a tool to your chain, so install it in an isolated environment as the readme recommends, to avoid dependency conflicts.
| Situation | Environment.yml alone | Add a lock file |
|---|---|---|
| Solo exploration | Fine | Optional |
| Shared analysis that must rerun | Risky | Recommended |
| Production job or image build | Risky | Recommended |
| Audit or evidence request | Weak | Strong |
A routine that works
- Edit environment.yml, since that is the intent.
- Regenerate the lock file in CI and commit it.
- Build images and environments only from the lock file.
- Scan the lock file contents on a schedule, because new advisories appear after you lock.
- Update packages deliberately, one by one, and re-lock.
For a broader look at pinning data projects see /resources/blog/pin-python-dependencies-in-data-projects.
Try it yourself
Click through it at your own pace, or open it full screen. Look for how a pinned package can still raise a new alert later.
Safeguard offers SBOM and dependency scanning, plus continuous monitoring, so a locked list can keep being checked. Run the free scan at gold.safeguard.sh/scan.
Quick check
Does conda-lock replace environment.yml?
No. It reads environment.yml as input and writes the solved result.
Is a locked environment automatically secure?
No. Locking fixes versions, and a fixed vulnerable version stays vulnerable.
Sources
- conda-lock README, conda project, fetched 19 October 2026.
Last reviewed: 19 October 2026.
