Commit Cargo.lock for applications and anything you ship as a binary, because it gives repeatable builds you can audit. For libraries it is optional, since the lock does not affect people who depend on your crate. Whatever you choose, run your own CI against a locked dependency set.
What the official FAQ says
The Cargo FAQ does not draw a hard line between libraries and binaries. It says that although cargo new tracks Cargo.lock in version control by default, whether you do depends on the needs of your package.
It adds a warning relevant to libraries: determinism can give a false sense of security, because Cargo.lock does not affect consumers of your package. Only Cargo.toml does that.
The FAQ lists benefits of committing the lockfile: deterministic builds, easier git bisect, consistent CI results and the ability to verify a minimum supported Rust version. The drawbacks it lists are merge conflicts, and the fact that cargo install ignores the lockfile unless you pass the locked flag.
Decision guide
You ship a binary, a service or a tool. Commit Cargo.lock. The artifact you release should come from known dependency versions, and reviewers can read the diff when a version changes.
You publish a library. Committing is optional, and there are two sound approaches.
- Commit it and use it in CI so your tests run on a fixed set, then add a separate scheduled job that updates the lock and tests against the newest versions.
- Do not commit it, and test against fresh resolutions so you notice breakage from new releases early.
Your downstream users will resolve their own versions either way.
You maintain a workspace with both. Commit one lock at the workspace root. It covers every member.
The supply chain angle
A lockfile is a record of exactly what was built. That has three uses.
- Review. A dependency update becomes a visible diff. A new crate in that diff deserves a look at who publishes it.
- Incident response. When a crate is reported malicious, a committed lock tells you in seconds whether you used it.
- Reproduction. You can rebuild an old release with the same inputs.
A lockfile does not make a dependency safe. It only freezes the choice. If you froze a bad version, you froze a bad version.
Install tips
- Use the locked flag with cargo install for tools you want to install exactly as published. Without it, the lockfile is ignored.
- In CI, build with the locked flag so the build fails if the lock would need to change, which catches accidental drift.
- Let a bot or a scheduled task propose updates in separate pull requests so each change is reviewed alone.
Pairing with scanning
Advisory databases for Rust crates work from names and versions, and a lockfile gives them exact versions to check. Safeguard scans Rust dependencies and produces SBOMs from them, so the lock becomes an inventory you can query.
Quick check
Does my library's Cargo.lock protect people who use my crate?
No. The FAQ states that Cargo.lock does not affect consumers of your package. Only Cargo.toml does.
Why did cargo install ignore my lockfile?
By default it ignores the lockfile unless you pass the locked flag, as the FAQ notes in its list of drawbacks.
Sources
Last reviewed: 19 October 2026.
