rust-lang/cargo: what the Rust package manager does and how to install it

The problem Cargo solves for Rust projects

The README states the job in one line: Cargo downloads your Rust project's dependencies and compiles your project. That covers the two chores that would otherwise be separate scripts in every repository. Dependency fetching is one, and it is not trivial, because the fetch layer has to speak to registries and to git remotes, over HTTPS and over SSH, with compression underneath. The compile step is the other, and it has to turn a dependency graph into an ordered build.

The audience is Rust developers. If you have a Cargo.toml and a src directory, Cargo is the tool that reads them. The README points new users at The Cargo Book for usage and at the Cargo Contributor Guide for people developing Cargo itself, which is a useful split: the repository you are looking at is the implementation, not the manual.

One line in the README is worth reading before anything else. The binary distributed with Rust is maintained by the Cargo team for use by the wider ecosystem. Every other use of the crate, as a binary or as a library, is maintained primarily for Cargo's own use and is not intended for external consumption except as a transitive dependency, and the crate may make major changes to its APIs. That is a clear boundary. If you were considering embedding Cargo's internals in your own tool, the project is telling you the API is not a contract.

How Cargo is put together, judging by the repository layout

The top level of the repository is a Rust workspace. Cargo.toml declares a [workspace] with resolver 2 and members drawn from crates/*, credential/*, benches/benchsuite and benches/capture. So the command-line tool in src/ is assembled from a set of internal crates rather than being one monolith, and the credential helpers live in their own directory alongside them.

Those helpers are named in the workspace dependency table: cargo-credential-libsecret, cargo-credential-macos-keychain and cargo-credential-wincred. That tells you how registry authentication is expected to work on each platform, through the platform's own secret store rather than a file Cargo manages itself. The shared trait crate is cargo-credential.

Several dependencies are pinned to specific versions in the workspace table, including cargo-util, cargo-util-schemas, cargo-platform, cargo-test-support and cargo_metadata. The presence of a dedicated test support crate, plus benches/benchsuite, indicates that testing and benchmarking are treated as first-class parts of the workspace rather than afterthoughts. The workspace also sets rust-version = "1.95" and edition = "2024" under [workspace.package], so building this repository from source needs a toolchain at least that new.

Network and transport work is delegated. The README lists libcurl for network transfers, libgit2 for fetching git dependencies, libssh2 for SSH access to git repositories, and libz for compression in those C libraries, while Rust code uses zlib-rs instead. Vendored copies of these are used unless the system provides them and pkg-config can find them.

Installing Cargo and building it from source

The README does not give an installation command. It says that to start using Cargo you should learn more at The Cargo Book, and the binary that most people run is the one distributed with Rust. So the documented route to a working cargo is the Rust distribution, not a standalone download from this repository.

If you want to build Cargo itself rather than use it, the README gives the steps. It requires cargo and rustc, a C compiler for your platform, and git to clone the repository.

git clone https://github.com/rust-lang/cargo.git
cd cargo

The README then gives the build command, run with cargo already installed.

cargo build --release

The README notes that pkg-config is optional and helps locate system packages such as the libssl headers and libraries. OpenSSL is only needed on Unix-like systems and only when the vendored-openssl Cargo feature is not used; with that feature, a static copy is built from source instead, which may need perl and make. On Windows, the system-provided Schannel is used instead. The README recommends the vendored versions of libcurl, libgit2, libssh2 and libz because those are the versions tested to work with Cargo.

Where Cargo is the wrong tool, and what the README does not promise

Cargo is a Rust package manager. The README frames it around a Rust project's dependencies and compiling that project, and nothing in the repository description suggests it manages other language ecosystems. If your repository is mostly C, C++ or Go with a small Rust component, Cargo will build the Rust part and nothing else, and you still need whatever build system the rest of the tree uses.

The second limitation is the crate boundary already quoted above. The README is explicit that uses of the cargo crate other than the Rust-distributed binary are maintained primarily for Cargo's own use, are not intended for external use except as a transitive dependency, and may see major API changes. Anyone planning to link against Cargo's internals should read that as a warning rather than a formality.

The third is documentation scope. The README is a pointer document: it sends users to The Cargo Book, contributors to the Contributor Guide, and release information to Rust's release notes and the changelog. It does not document installation, rollback or upgrade procedures for the binary itself. The README does not document rollback. Neither does it list a version number for the current release, because, as it states, Cargo releases coincide with Rust releases. If you need to know what changed between two versions, the changelog is the source the README names, not this page.

Cargo compared with a language-agnostic build tool

The obvious alternative for a mixed-language repository is a general build orchestrator such as Make or a task runner that shells out to whatever compiler each part of the tree needs. The difference in approach is the dependency graph. A Makefile knows about file timestamps and explicit rules; you write the rule that says object files depend on sources. Cargo instead reads a manifest, resolves versions across a package registry and git remotes, and derives the build order from that resolved graph, which is why the README can describe the tool as both downloading dependencies and compiling the project in the same breath.

That difference cuts both ways. Cargo's model gives you reproducible dependency resolution and a single command for build, test and fetch, but it only understands crates. A Makefile understands everything and guarantees nothing about versions. For a pure Rust project the trade is not close. For a polyglot monorepo, Cargo is a component inside someone else's orchestration, and the README offers no integration story for that case.

The second alternative worth naming is writing your own subcommand. The README states that Cargo is designed to be extensible with new subcommands without having to modify Cargo itself, and links to a wiki page with details and a list of known community-developed subcommands. That is the supported extension point, and it is a much better bet than depending on the internal crates.

Maintenance, upgrade cost and licence terms

The repository is not archived, and the last push was on 2026-09-20, so the project is being worked on. That says nothing about the stability of the command-line interface you use, which is governed by the Rust release cycle rather than by commits to this repository.

Upgrade cost is tied to that cycle. The README states that Cargo releases coincide with Rust releases, with high level release notes in Rust's release notes and detailed release notes in the changelog. So upgrading Cargo in practice means upgrading the toolchain, and the changelog is where you check what moved. Building the repository from source has its own floor: the workspace sets rust-version = "1.95" and edition = "2024", and the README lists cargo, rustc, a C compiler and git as requirements, with pkg-config and OpenSSL optional depending on platform and on whether the vendored-openssl feature is used.

On licensing, the README says Cargo is primarily distributed under the terms of both the MIT license and the Apache License (Version 2.0), with LICENSE-MIT and LICENSE-APACHE in the repository. The workspace manifest agrees, setting license = "MIT OR Apache-2.0". Two further notes appear in the README. The product includes software developed by the OpenSSL Project, and in binary form it includes software licensed under the GNU General Public License, version 2, with a linking exception, obtainable from the upstream repository. LICENSE-THIRD-PARTY covers the details. If you redistribute Cargo in binary form, those third-party terms are the ones to read; this is a description of what the files say, not legal advice.

Editorial conclusion

Adopt Cargo if you are writing Rust and want dependency resolution and builds behind one command; the binary shipped with Rust is the supported path. Do not adopt it as a general-purpose build tool for non-Rust codebases, and do not consume the cargo crate as a library, since the README says it is maintained primarily for Cargo's own use and may make major API changes. Verify first that your toolchain is new enough for the workspace MSRV of 1.95 and edition 2024, and read the changelog rather than assuming an upgrade is routine.

Frequently asked questions

Official sources

1. Issues
2. License: Apache-2.0
3. Project website
4. README
5. rust-lang/cargo on GitHub