Commit Cargo.lock for applications and binaries. For a library it is optional, and it never reaches the people who depend on you, because the Cargo Book says the lockfile does not affect consumers of your package, only Cargo.toml does. When in doubt, the same book says to check it in.
Two files, two jobs
The Cargo Book explains the split. Cargo.toml describes your dependencies in a broad sense and is written by you. Cargo.lock contains exact information about your dependencies and is maintained by Cargo, not edited by hand.
Cargo's default requirement style is the caret. A requirement written as 1.2.3 means the same as ^1.2.3, which allows SemVer compatible updates. Tilde requirements allow less movement, wildcard requirements allow more, and crates.io rejects bare star requirements.
What the lockfile buys you
The Cargo FAQ says the lockfile describes the state of the world at the time of a successful build, and gives deterministic builds across times and machines. It lists practical benefits:
- running git bisect to find the cause of a bug with the same dependencies each time
- making CI fail only because of new commits, not external changes
- reducing confusion when contributors see different behavior from each other or from CI
The false sense of security
The same FAQ warns that determinism can give a false sense of security. Two examples from the book: cargo install selects the latest dependencies unless you pass the locked option, and new dependencies added with cargo add are locked to the latest version at that moment.
So committing the lockfile fixes what your own builds use. It does not fix what a user gets when they install your crate from source. If you ship a command line tool through cargo install, tell users about the locked option:
cargo install --locked your-tool
The install documentation spells out the tradeoff. Using the locked option uses the exact set of dependencies from when the package was published, which helps reproducibility and avoids a newer dependency that no longer builds. The downside is that you receive no fixes or updates to any dependency. It also notes that Cargo only started publishing Cargo.lock files with version 1.37, so older packages may not have one.
Decision guide
| You ship | Commit Cargo.lock? | Why |
|---|---|---|
| A server, service or app | Yes | You deploy what you tested |
| A command line tool | Yes | Plus advise the locked option for installs |
| A library only | Your call | Consumers ignore it, but your CI benefits |
| A library with a binary | Yes | The binary needs reproducibility |
For libraries that skip the lockfile, the Cargo documentation points to verifying the latest dependencies in CI, so you learn early when a new release of a dependency breaks you.
Keep the loose side honest
Because libraries are tested against whatever the newest compatible versions are, state ranges you have really exercised. Do not use a star requirement. The FAQ is blunt: a requirement of star says it works with every version ever, which is never going to be true, and libraries should specify the range they work with, even something as general as every 1.x.y version.
Where Safeguard fits
Whether you lock or not, you should know what resolved. Safeguard's dependency scanning and SBOM generation can inventory a Rust project's tree and flag known vulnerabilities, and you can try a free scan at gold.safeguard.sh/scan.
Quick check
Will users of my crate get my Cargo.lock?
No. The Cargo Book says the lockfile does not affect consumers of your package. They resolve from your Cargo.toml requirements.
Does cargo install use the lockfile by default?
No. It selects the latest dependencies unless you pass the locked option, according to the Cargo FAQ.
Sources
- The Cargo Book: Specifying dependencies
- The Cargo Book: FAQ
- The Cargo Book: Cargo.toml vs Cargo.lock
- The Cargo Book: cargo install
Last reviewed: 19 October 2026.
