Yes. For a service or any binary you ship, commit Cargo.lock. Cargo's own FAQ says the lock file describes the state of the world at the time of a successful build, which makes builds deterministic. For a library, the lock file does not reach the people who depend on you, so the case is weaker.
What the Cargo FAQ says
The Cargo FAQ notes that cargo new defaults to tracking Cargo.lock in version control, but that whether you do depends on the needs of your package. It states the purpose plainly: "to describe the state of the world at the time of a successful build". Reasons it lists include running git bisect, making sure CI fails only because of new commits, and reducing confusion between contributors and CI.
It also adds a caution. Determinism can give a false sense of security, because Cargo.lock does not affect the consumers of your package, only Cargo.toml does. As an example, cargo install picks the latest dependencies unless the locked flag is passed.
Service or library
| You ship | Commit Cargo.lock? | Why |
|---|---|---|
| A web service or API | Yes | Production should run what CI tested and scanned |
| A command line tool or agent | Yes | Same reasoning, and users may build from source |
| A library only | Optional | Consumers resolve their own versions from Cargo.toml |
| A workspace with services and libraries | Yes, one lock file at the root | Services in the workspace share it |
For a workspace, Cargo uses one lock file at the root, which is also why the related post on workspace dependencies and a shared lock file is worth reading.
The security argument
Without a committed lock file, two builds of the same commit on different days can pick different dependency versions. That means:
- A vulnerability scan of the repository does not describe what you deployed.
- A newly published malicious version can enter a build with no code change.
- A bug that appears only in production cannot be reproduced by rebuilding the same commit.
A committed lock file turns dependency updates into visible diffs. Combine it with locked builds in CI, so a build that would change the file fails instead.
Handling updates
A lock file is not a freeze forever. Update on purpose.
- Run cargo update on a schedule, or per advisory, in its own pull request.
- Read the diff. Look for new crates, new maintainers and unexpected version jumps.
- Run the test suite and an advisory scan on that pull request.
- For one vulnerable crate, update only that crate. The post on cargo update with precise shows how.
- Merge, and let the locked CI build confirm.
Try it yourself
Click through it at your own pace, or open it full screen. See how a dependency inventory is read from lock data, and what happens when it is missing.
Quick check
Will a committed lock file cause merge conflicts?
Sometimes. The Cargo FAQ mentions this. Resolving them is usually a matter of re running a Cargo command and committing the result, and the trade is worth it for a service.
Does a lock file protect me from a bad crate?
It protects you from unreviewed changes after it was written. It does not judge whether the pinned crates are safe, so scan them.
Safeguard dependency scanning and SBOM generation work from your lock file, and the free scan is at gold.safeguard.sh/scan.
Sources
Last reviewed: 19 October 2026.
