How to vendor Rust dependencies with cargo vendor for offline builds

Step 01: Commit a current Cargo.lock

While online, build once or run:

cargo generate-lockfile
git add Cargo.lock

If you already build in CI with --locked, you are done with this step.

Step 02: Run cargo vendor

cargo vendor

Our demo project had a single line in [dependencies], serde_json = "1". Cargo vendored 11 crates in 0.48 seconds (they were already in the local cache; a cold run downloads them first): itoa, memchr, proc-macro2, quote, serde, serde_core, serde_derive, serde_json, syn, unicode-ident and zmij.

Our run on Windows, cargo 1.91.0, Oct 26 2026. Trimmed: 7 of the 11 "Vendoring" lines and the local cache paths are cut for width.

Two details people miss. First, the folder holds more crates than your build uses: cargo tree showed 5 crates in the active tree, but vendor also copied serde_derive, syn, quote, proc-macro2 and unicode-ident, because the lockfile covers every feature and platform. Second, size is dominated by a few big crates. syn alone was 2,318 KB of our 5,806 KB. If the folder gets heavy, cargo-vendor-filterer drops crates for platforms you never build.

Useful flags from the cargo vendor docs: --versioned-dirs puts the version in every folder name (cleaner diffs when re-vendoring), -s path/to/Cargo.toml vendors extra workspaces into the same folder, and --locked fails instead of changing your lockfile.

Step 03: Point Cargo at vendor/

cargo vendor prints exactly what to add. Put it in .cargo/config.toml at the project root:

[source.crates-io]
replace-with = "vendored-sources"

[source.vendored-sources]
directory = "vendor"

This is Cargo's source replacement: every request for a crates.io crate is answered from the directory instead. The Cargo book is strict about one rule here: the replacement must hold exactly the same code as the original, which is why you should never hand-edit files under vendor/. Each crate carries a .cargo-checksum.json, and Cargo treats vendored sources as read-only. To change a dependency, use [patch] or a path dependency.

Step 04: Prove it with no network and an empty cache

--offline alone can fool you, because Cargo may still find crates in your global cache (~/.cargo/registry). Point CARGO_HOME at an empty folder so the only possible source is vendor/:

CARGO_HOME=/tmp/empty-cargo-home cargo build --offline --locked

On Windows PowerShell: $env:CARGO_HOME="C:\temp\empty"; cargo build --offline --locked.

We ran the cheaper check, cargo tree --offline --locked, with an empty CARGO_HOME, and the full tree resolved from vendor/. Then we tried to add a crate we had not vendored, cargo add --offline anyhow@1, and got the failure you want to see: error: the crate anyhow@1 could not be found in registry index. Nothing leaked in from the network.

Step 05: Ship vendor/ with the source

Two common options:

• Commit it. Simplest for air-gapped or regulated builds. Our 11-crate demo was under 6 MB; real services often run to hundreds of MB, so consider Git LFS or a separate branch.
• Archive it. tar czf src-with-vendor.tgz Cargo.toml Cargo.lock .cargo src vendor gives the offline machine one file to unpack.

Step 06: Re-vendor when dependencies change

cargo vendor deletes and rewrites vendor/ by default (pass --no-delete to keep old contents). After cargo update or a new dependency, run it again online, review the diff, commit. Put cargo build --offline --locked in CI so a dependency added without re-vendoring fails the build the day it lands, not the day the network goes.