A Rust project’s lockfile records a dependency-resolution decision, but a build also depends on network availability, cached crates, the compiler, and the surrounding toolchain. Cargo offers flags that control some of those inputs. Using them well requires knowing which question each flag answers rather than treating every restricted build as the same kind of reproducibility guarantee.
The Cargo build reference distinguishes locked, offline, and frozen operation. Locked constrains lockfile changes, offline prevents Cargo’s network access, and frozen combines both. This guide explains how to turn those specific behaviors into a maintainable build contract without claiming they certify dependency safety or guarantee identical output bytes.
Locked protects an existing resolution
Cargo documents that –locked asserts the same dependencies and versions as the existing Cargo.lock file. The command exits with an error if the lockfile is missing or if Cargo attempts to change it because dependency resolution differs. That makes unexpected graph changes visible during a build.
The flag is useful when automation should consume a reviewed project state rather than silently update it. A missing or inconsistent lockfile should lead to deliberate maintenance, not a last-minute change inside a release runner. Keep the manifest and lockfile relationship understandable in version control and code review.
Locked does not mean every dependency is safe. It means the dependency versions are constrained by a recorded resolution. A vulnerable crate can be consistently selected, and a stable graph can still contain a package you did not intend to trust. Dependency review and supported updates remain separate responsibilities.
Offline changes network behavior
The reference says –offline prevents Cargo from accessing the network. Cargo attempts to proceed using locally available material, but only when that is possible. This is not a promise that every project can build without first retrieving the crates and other inputs it requires.
Cargo also warns that offline operation can lead to a different resolution than online operation because the available local crates constrain selection. A local index may indicate a newer version exists while the corresponding crate has not been downloaded. Offline availability and dependency selection are therefore related, but they are not identical controls.
If the goal is to keep the existing resolution and avoid Cargo network activity, use the documented combination rather than assuming offline alone implies locked behavior. Explain that intent in the build configuration so another maintainer understands why a missing local dependency should produce a failure rather than a surprise fallback.
Frozen combines the two constraints
Cargo describes –frozen as equivalent to –locked plus –offline. It is a concise way to require an existing unchanged resolution and operate without Cargo’s network retrieval. The build still needs the relevant dependency material to be available locally before the frozen stage begins.
Separate preparation from the constrained build when that fits the pipeline. The reference points to cargo fetch for downloading dependencies before offline work. Use the project’s intended target and configuration during preparation so the local material matches what the later job actually needs.
Do not describe frozen as a universal machine-wide network firewall. The documented flag controls Cargo’s behavior; it is not an operating-system security boundary for every executable involved in compilation. If the threat model requires preventing all build processes from contacting a network, enforce that requirement through the runner’s actual network policy as well.
Record the compiler and target separately
The dependency graph does not identify every component of the build. Record the supported Rust toolchain, target architecture, operating system or container image, and any external compiler or linker requirements. Native libraries and platform-specific configuration can affect compilation even when Cargo.lock is unchanged.
For cross-compilation, make the intended target explicit throughout dependency preparation, compilation, and testing. A cache populated for one environment should not be assumed to contain every input needed for another. Test the actual target path rather than treating a successful host build as equivalent evidence.
Change these inputs deliberately. Updating the compiler, crate graph, operating system, and release profile together creates a larger diagnostic problem when the result fails. Where practical, stage the changes so their effects can be inspected separately and the release record explains what changed.
Decide where dependency updates belong
A locked build should fail rather than invent a new resolution when its inputs disagree. That failure is a useful boundary between development and release verification. Fix the inconsistency in a reviewed working branch, run the supported tests, and commit the intended updated inputs before trying the release build again.
Do not remove –locked from a pipeline simply to make a red job green. First inspect whether the lockfile is missing, stale, or inconsistent with a deliberate manifest change. The resolution may need updating, but the update should be part of the application change rather than an undocumented side effect of automation.
For maintainers of different kinds of Rust projects, follow the project’s documented lockfile policy. The existence of Cargo’s flags does not eliminate policy decisions about how dependency versions are managed. The important point is that the build environment and the repository’s intended contract agree.
Make cache requirements observable
An offline build depends on local availability. Document how the required crate material reaches the runner, how caches are refreshed, and what happens when the cache is missing. Otherwise, a pipeline may work for months and then fail on a new machine that never received the hidden prerequisite.
Exercise that new-runner path deliberately. Prepare dependencies through an approved connected stage, then verify the frozen build in the intended constrained stage. Keep the resulting evidence scoped: success demonstrates the tested input set was available, not that every future dependency update will automatically work offline.
Protect cached material and preparation credentials according to the environment’s policy. A private registry token should not be copied into general build artifacts or retained in verbose logs. Build convenience is not a reason to make a long-lived credential available to jobs that only need local crate files.
Keep execution trust separate
Compilation is an execution environment, not merely a text transformation. Review the trust and permissions of the code and tools involved. A fixed dependency graph does not justify access to production credentials, administrator privileges, or unrelated confidential files during a build.
Use a runner with the smallest practical authority for the job and separate release publication from ordinary compilation when the workflow supports it. A toolchain that produces an artifact does not automatically need the credentials that deploy that artifact to production. The boundary should be explicit and independently tested.
The same principle applies to unfamiliar repositories. Passing –frozen does not make executing their build process safe. Inspect the project, understand its setup requirements, and use an appropriate restricted environment before running code whose origin or behavior you have not established.
Validate more than compilation success
Run the project’s supported tests and representative application checks after the constrained build. A crate graph may compile successfully while changes in behavior, platform assumptions, or external services break the workload. Compilation is one outcome, not the full application acceptance test.
If exact artifact reproducibility is a requirement, evaluate the complete build process for that property. Compiler settings, external tools, embedded metadata, and platform inputs can matter beyond dependency resolution. Avoid advertising byte-identical output merely because a build used Cargo.lock and –locked.
The takeaway is a precise separation of controls. Locked keeps the existing resolution unchanged, offline prevents Cargo network access, and frozen combines those requirements. Prepare the necessary inputs, record the surrounding toolchain, and test the application you will deploy. Those practices make constrained Rust builds useful and diagnosable without turning a small set of flags into a security or reproducibility promise they cannot independently fulfill.
