A Conan lockfile is a snapshot of your resolved dependency graph, recording each package version and its revision. Create it with conan lock create ., commit conan.lock, and pass it explicitly in CI. Version ranges then resolve only to locked entries until you update the file on purpose.
What problem it solves
Conan recipes often declare version ranges. A range such as a minor version window resolves to the newest match at the time you run it. The same project can therefore build against a different library tomorrow without any change to your code. The Conan documentation shows exactly this: the same install moving from one version to the next as new releases were published.
A lockfile freezes the result. The documentation describes it as a mechanism for reproducible dependencies even when newer versions or revisions are published.
Create and use one
conan lock create .
conan install . --lockfile=conan.lock
Each entry records a version and a revision, in the form name/version#revision plus a timestamp. If a conan.lock file exists, Conan picks it up implicitly for commands such as install, graph info and create. The documentation says passing the lockfile explicitly is better in CI, so a missing file fails loudly rather than being ignored.
What it does not do
- It cannot force a version outside the range a recipe declares.
- Lockfiles are strict by default. A dependency missing from the lockfile is an error, unless you relax that with the partial option.
- Packages that apply only to other configurations are left out unless you create the lock for that configuration, for example a different architecture. Teams that build for several platforms create one lockfile per configuration, and the documentation notes a merge command that is best left to CI scripts.
Updating on purpose
A lockfile is a decision log, not a freeze forever. When an advisory affects a locked library, update deliberately:
- Raise the requirement in the recipe, or relax the range if needed.
- Regenerate the lockfile for each configuration.
- Review the diff in version control. A changed revision line is as meaningful as a changed version.
- Rebuild, run tests, and commit.
Treat the diff like a dependency change in any other ecosystem. Reviewers should see exactly which libraries moved.
Try it yourself
Open the demo to see how a pinned inventory makes it easy to spot a component that has a known fix available. Look for the version column and what changes when a fix is applied.
Click through it at your own pace, or open it full screen.
Quick check
Does Conan use the lockfile without being told?
If a conan.lock file is found, Conan uses it implicitly with commands like install and graph info. In CI, pass it explicitly.
Will a newer library release be ignored?
Yes, until the lockfile is updated. That is the point, and also why you need a scheduled update.
Safeguard's SBOM and dependency scanning can build an inventory of the components in a repository, and the free scan at gold.safeguard.sh/scan is a quick way to see what turns up.
Sources
Last reviewed: 19 October 2026.
