cargo-vendor

Vendor dependencies and configure cargo to use the vendored sources in the current project

$ cargo vendor [path/to/directory] > .cargo/config.toml

cargo vendor [OPTIONS]

--output
    Specifies the directory where dependencies should be vendored. If not provided, it defaults to .cargo/vendor in the workspace root.

--respect-source-path
    By default, cargo-vendor adds source replacement entries to .cargo/config.toml. This option prevents that, requiring manual configuration of the vendored path.

--sync
    Synchronizes the vendored directory with Cargo.lock, removing any unused dependencies and adding new ones.

--verbose, -v
    Use verbose output, showing more details about the vendoring process.

--quiet, -q
    Do not print cargo log messages, silencing most output.

--manifest-path
    Path to the Cargo.toml file for the package or workspace being vendored.

--target
    Vendor dependencies specifically for the given target triple (e.g., x86_64-unknown-linux-gnu).

--locked
    Requires Cargo.lock to be up to date. If it's not, cargo-vendor will exit with an error.

--no-default-features
    Do not enable default features for the root package.

--all-features
    Enable all features for the root package.

--features
    A space-separated list of features to enable for the root package.

--workspace
    Vendor all dependencies for all packages in the current workspace.

--version
    Print cargo-vendor's version information and exit.

--help
    Prints help information about the command.

`cargo-vendor` is a subcommand of the Rust package manager, cargo, designed to copy all Git and Registry dependencies required by a Rust project into a local directory. This process, known as "vendoring," allows projects to be built without an active internet connection, making it invaluable for offline development, reproducible builds, and deployment in air-gapped environments.

When executed, `cargo-vendor` fetches all necessary crates and places them into a specified output directory (by default, .cargo/vendor relative to the workspace root). Crucially, it also updates the project's .cargo/config.toml file to redirect cargo's source resolution to these locally vendored dependencies instead of the network. This ensures that subsequent build commands (e.g., `cargo build`, `cargo test`) will use the copied dependencies, guaranteeing consistency and eliminating external network reliance. It's a fundamental tool for managing project dependencies in controlled or restricted environments.

By default, `cargo-vendor` does not vendor build-dependencies or dev-dependencies unless they are also regular dependencies.
The vendored directory can become quite large, especially for projects with many dependencies, which can impact disk space and version control repository size if committed.
Managing vendored dependencies manually (e.g., outside of `cargo-vendor --sync`) can lead to inconsistencies between the Cargo.lock and the actual vendored crates.

When `cargo-vendor` runs, it modifies or creates a .cargo/config.toml file in the project's .cargo directory. This file contains source replacement entries that redirect cargo to use the locally vendored dependencies instead of fetching them from crates.io or Git repositories. These entries typically look like:
[source.'crates-io']
replace-with = "vendored-sources"

[source.vendored-sources]
directory = "vendor"
(where "vendor" is the path specified by --output).

A common workflow involves running `cargo vendor` once to populate the local directory. The .cargo/config.toml and the vendored directory (e.g., .cargo/vendor) are then often committed to version control. This ensures that anyone cloning the repository can build the project immediately without requiring an internet connection, relying solely on the vendored dependencies.

The `cargo-vendor` subcommand was introduced to address the growing need for offline compilation and reproducible builds within the Rust ecosystem. It was integrated into cargo to provide a standardized, convenient way to "snapshot" dependencies, moving beyond manual methods or ad-hoc scripts. Its development reflects the Rust community's focus on robust tooling and support for diverse development environments, including those with restricted network access or strict build requirements.

cargo(1), cargo-build(1), cargo-fetch(1), cargo-update(1)