A cargo subcommand for displaying when Rust dependencies are out of date

Clone the project $ git clone && cd cargo-outdated




cargo-outdated is for displaying when dependencies have newer versions available.

How it works

The functionality of cargo-outdated largely depends on the cargo builtin command cargo update.

To retrieve the list of available SemVer compatible dependencies, cargo-outdated firstly creates a temporary workspace, then executes cargo update against it, finally compares the temporary dependency tree with the original one.

Similarly, to check the latest dependencies, cargo-outdated replaces the SemVer requirements of direct dependencies with wildcards then goes through the same process.


Once installed (see below) running cargo outdated in a project directory looks like the following:

$ cargo outdated
Name             Project  Compat  Latest   Kind         Platform
----             -------  ------  ------   ----         --------
clap             2.20.0   2.20.5  2.26.0   Normal       ---
clap->bitflags   0.7.0    ---     0.9.1    Normal       ---
clap->libc       0.2.18   0.2.29  Removed  Normal       ---
clap->term_size  0.2.1    0.2.3   0.3.0    Normal       ---
clap->vec_map    0.6.0    ---     0.8.0    Normal       ---
num_cpus         1.6.0    ---     1.6.2    Development  ---
num_cpus->libc   0.2.18   0.2.29  0.2.29   Normal       ---
pkg-config       0.3.8    0.3.9   0.3.9    Build        ---
term             0.4.5    ---     0.4.6    Normal       ---
term_size->libc  0.2.18   0.2.29  0.2.29   Normal       cfg(not(target_os = "windows"))


The latest version of cargo-outdated can be installed or updated with cargo install:

cargo install --locked cargo-outdated


cargo install --locked --git https://github.com/kbknapp/cargo-outdated


Follow these instructions to compile cargo-outdated, then skip down to Installation.

  1. Ensure you have current version of cargo and Rust installed
  2. Clone the project $ git clone https://github.com/kbknapp/cargo-outdated && cd cargo-outdated
  3. Build the project $ cargo build --release
  4. Once complete, the binary will be located at target/release/cargo-outdated

Installation and Usage

All you need to do is place cargo-outdated somewhere in your $PATH. Then run cargo outdated anywhere in your project directory. For full details see below.

Linux / OS X

You have two options, place cargo-outdated into a directory that is already located in your $PATH variable (To see which directories those are, open a terminal and type echo "${PATH//:/\n}", the quotation marks are important), or you can add a custom directory to your $PATH

Option 1 If you have write permission to a directory listed in your $PATH or you have root permission (or via sudo), simply copy the cargo-outdated to that directory # sudo cp cargo-outdated /usr/local/bin

Option 2 If you do not have root, sudo, or write permission to any directory already in $PATH you can create a directory inside your home directory, and add that. Many people use $HOME/.bin to keep it hidden (and not clutter your home directory), or $HOME/bin if you want it to be always visible. Here is an example to make the directory, add it to $PATH, and copy cargo-outdated there.

Simply change bin to whatever you'd like to name the directory, and .bashrc to whatever your shell startup file is (usually .bashrc, .bash_profile, or .zshrc)

mkdir ~/bin
echo "export PATH=$PATH:$HOME/bin" >> ~/.bashrc
cp cargo-outdated ~/bin
source ~/.bashrc


This library depends on OpenSSL. On MacOS a newer version of OpenSSL than is installed by default is needed. This can be installed with Homebrew via brew install openssl or openssl can be vendored in with --features vendored-openssl. Learn more about building OpenSSL here,


On Windows 7/8 you can add directory to the PATH variable by opening a command line as an administrator and running

setx path "%path%;C:\path\to\cargo-outdated\binary"

Otherwise, ensure you have the cargo-outdated binary in the directory which you operating in the command line from, because Windows automatically adds your current directory to PATH (i.e. if you open a command line to C:\my_project\ to use cargo-outdated ensure cargo-outdated.exe is inside that directory as well).


There are a few options for using cargo-outdated which should be somewhat self explanatory.

Displays information about project dependency versions

    cargo outdated [options]

    -a, --aggressive            Ignores channels for latest updates
    -h, --help                  Prints help information
        --format FORMAT         Output formatting [default: list]
                                [values: list, json]
    -i, --ignore DEPENDENCIES   Comma separated list of dependencies to not print in the output
    -x, --exclude DEPENDENCIES  Comma separated list of dependencies to exclude from building
    -q, --quiet                 Suppresses warnings
    -R, --root-deps-only        Only check root dependencies (Equivalent to --depth=1)
    -V, --version               Prints version information
    -v, --verbose ...           Use verbose output
    -w, --workspace             Checks updates for all workspace members rather than
                                only the root package
        --color COLOR           Coloring: auto, always, never [default: auto]
                                [values: auto, always, never]
    -d, --depth NUM             How deep in the dependency chain to search
                                (Defaults to all dependencies when omitted)
        --exit-code NUM         The exit code to return on new versions found [default: 0]
        --features FEATURES     Space-separated list of features
    -m, --manifest-path FILE    Path to the Cargo.toml file to use
                                (Defaults to Cargo.toml in project root)
    -p, --packages PKGS         Packages to inspect for updates
    -r, --root ROOT             Package to treat as the root package


cargo-outdated is released under the terms of either the MIT or Apache 2.0 license. See the LICENSE-MIT or LICENSE-APACHE file for the details.


Collection of the latest Issues



Comment Icon0


cargo outdated fails to run when a project specifies a custom target file:

I assume that the custom target file is not copied over to the temporary copy of the project, so cargo cannot find it and fails to run.


Here's a script to reproduce a MWE:

The first argument is the name of the project directory:


There might be two ways to solve this problem:

  1. also copy over the custom target .json
  2. delete build.target from .cargo/config{,.toml}

I tried my hands at a (crude) implementation of 2., that seems to work:



Comment Icon0

I've been writing a few xtasks recently and I want to statically include cargo-outdated in my xtasks binary.

Are there any reasons why cargo outdated should not have a lib.rs and API? cargo-edit allows for linking as a lib, so it's possible.

The benefits of statically linking cargo-outdated into an xtask binary are:

  • Provide more detailed data from the lib API.
  • Allow the user to provide dependencies such as cargo_metadata::Metadata.
  • Avoid other team members having to install various cargo plugins.

The use case that triggered this request is:

I want to make an xtask that lists outdated dependencies and interactively allows the user to update the version in Cargo.toml.

This can already be solved as the json output includes the crate_name and I can go search for the crate by name in the current dir. Or I could include add cargo_file_path to the json output to avoid searching my project workspace for something cargo-outdated already knows.

What I would like is to simply be able to:

  • Call cargo-outdated through an API
  • Give it the crate metadata
  • Specify some options (the API equivalent of --root-deps-only)
  • Get back detailed information about the dependencies, including the path to the packages Cargo.toml. Maybe just return the cargo_metadata::Package?


Comment Icon2

Ubuntu with rustc, v1.58.1, cargo-outdated 0.10.2

Running cargo outdated I get

When creating a new user on the same system and

  • installing rust, cargo, cargo-outdated for that user
  • cloning the repository
  • then cargo outdated works just fine.

So, my guess is that something in ~/.cargo is wrong. If I knew what causes it I could perhaps cleanup things in ~/.cargo



Comment Icon0

cargo-outdated currently forcibly enables all targets when it resolves the workspace's dependencies: https://github.com/kbknapp/cargo-outdated/blob/fe97a089185162ffb84b91e6ce24eabf96784b62/src/cargo_ops/elaborate_workspace.rs#L90

This means that cargo-outdated will download dependencies that aren't needed for cargo build and friends, causing unnecessary network traffic, and potentially requiring network access when cargo build would not. Most Cargo tools default to only taking the current host platform into account unless another target is specifically given, but given cargo-outdated's use-case, it may make sense to instead follow the pattern of cargo metadata, which takes a --filter-platform argument to limit the search only to the given target platform when passed.

Beyond being slightly inconvenient, the lack of this particular feature is also a hurdle in strictly managed Rust build settings where the entirety of crates.io is not necessarily available, such as due to licensing constraints. As an example, imagine my crate has a dependency on some crate foo, which in turn has a target.cfg(windows).dependencies on the LGPL-3.0-licensed rug crate. Due to its license, rug is not available in my build environment. But I'm not building for Windows, so do not need rug at all, and so everything is fine! Except if I try to run cargo-outdated, because it tries to fetch dependencies for all targets, which includes the (unused) rug dependency.

As an addendum, I was surprised that cargo-outdated decides to download transitive dependencies even when -R flag is passed. In fact, it's weird to me that it needs to download dependencies at all. It stems from the call to cargo::get_many here: https://github.com/kbknapp/cargo-outdated/blob/fe97a089185162ffb84b91e6ce24eabf96784b62/src/cargo_ops/elaborate_workspace.rs#L98

Which doesn't feel like it's actually necessary — isn't the information in the index alone sufficient? Specifically, I wonder if you could just use PackageSet::packages the way cargo metadata does instead, and still have all the information you need? https://github.com/rust-lang/cargo/blob/58a961314437258065e23cb6316dfc121d96fb71/src/cargo/ops/cargo_output_metadata.rs#L136

That would almost certainly remove the need to add --filter-platform, since you wouldn't be downloading anything.



Comment Icon0

We're trying to update Homebrew's version of libgit2 to 1.2.0 at Homebrew/homebrew-core#84518. While testing dependent packages, CI encountered the following error which I've managed to reproduce locally:

For reference, demo-crate contains only a Cargo.toml and lib.rs:

Strangely enough, this only occurs on Intel macOS (reproduced on Mojave, Catalina, and Big Sur). It does not happen on ARM macOS.

Any assistance would be appreciated.



Comment Icon0

I've come across a situation where cargo outdated fails with the error failed to resolve patches for https://github.com/rust-lang/crates.io-index.

This happens when:

  • a dependency that is not published on crates.io is specified with a regular version
  • A (workspace) [patch] override specifies a local path for said dependency






Comment Icon1

Version cargo-outdated v0.9.17

My project saved its dependecies via cargo vendor

Using cargo outdated in this workspace fails with

Removing all the vendoring stuff and the .cargo/config.toml helps and re-vendor afterwards but feels laborious



D: difficult
Comment Icon0

I have a large workspace that has many crates and depends on many more.

Running cargo outdated takes forever at the root of the workspace. However if only checking depth of 1, completes immediately (cargo outdated -d 1).

We should investigate whatever is taking so long; however, looking through an entire workspace of dependencies for outdated crates is a bit..ill advised so this is not a major priority right now.



Comment Icon9

cargo::core::resolver::ResolveOpts changed, so it's more than just bumping the cargo dependency.

For context, the new resolver https://blog.rust-lang.org/2021/03/25/Rust-1.51.0.html#cargos-new-feature-resolver no longer needs a cargo-feature activated to work, which the current release (with cargo 0.50) claims. The new resolver does however solve a lot of outstanding issues, which I think will result in a lot of crate updates, which it would be great to discover with cargo outdated :)



D: medium
Comment Icon0

The documentation for Cargo configuration indicates that .cargo/config files may be present at any parent directory of the current project, and that they will all be read and unified. However, at the moment, cargo outdated only copies over .cargo/config if it is in the workspace root: https://github.com/kbknapp/cargo-outdated/blob/d09073947bfc481e861a2dc08a568cefce355c1a/src/cargo_ops/temp_project.rs#L122

That code should be updated to search up the stack, and unify config files as it goes (though it's not clear how that unification works in cargo?).



Comment Icon0

I use a paths override in .cargo/config

when working on two related crates that reside in different repos. cargo-outdated doesn't like that at all and merely panics:

Apparently related to #188, merged with a quite prophetic comment

Let's see how that works. Hopefully people won't be using things like index path override that uses a relative path.

Well, people do use things like that...

Personally I don't care about respecting the paths override, a helpful error message saying something along the lines of "you're doing something unsupported in .cargo/config" should be fine. Just don't want to spend twenty minutes trying to make sense of why it's panicking.



D: medium
Comment Icon4

Thanks for outdated - it's super useful - and I've used it successfully in the past. However, today, running the latest version of cargo outdated (installed 10 mins ago) I get the error:

This is using a private codebase, where foo is not really foo but a different internal package. That package foo is used by about 7 projects with a workspace. None of these constrain the version. Any idea what causes this condition? Any way to improve the error to indicate what the problem might be? Any useful information I can provide?



T: enhancement
Comment Icon0

It would be useful for code reviewing purposes to allow dependencies from a private registry to be completely ignored. My current solution to this involves removing dependencies from the private registry from the cargo.toml before running cargo outdated.



T: new feature
Comment Icon0

It would be useful have an option for printing the crate release dates alongside the current and latest versions to help get a good idea of a project's approach to updating dependencies.



T: bug
Comment Icon1

I built a copy of cargo-outdated on OS X 10.10, with:

cargo-outdated$ rustc --version rustc 1.43.0 (4fb7144ed 2020-04-20) cargo-outdated$ cargo --version cargo 1.43.0 (3532cf738 2020-03-17)

I had to jump through some hoops to get this to build, due to weirdnesses with my local libiconv libraries. (Documented in #187 and in this git2-rs issue.) However, as I explained in the comments to #187, even if (strategy 1) I disable the use of libiconv on my system, and confirm that the generated binary doesn't use it, I still get segfaults upon use. I also get segfaults when (strategy 2) I do use libiconv, but make sure that it's the system version that's linked against, rather than the macports version.

The results I see in strategy 1 testify to the problem not being one that involves the libiconv idiosyncrasies here. But strategy 2 is simpler to show how to reproduce, so I'll do that here:

cargo-outdated$ ls -l ./lib total 48 lrwxr-xr-x 1 jim wheel 31 May 6 07:24 libcharset.1.0.0.dylib -> /usr/lib/libcharset.1.0.0.dylib lrwxr-xr-x 1 jim wheel 27 May 6 07:24 libcharset.1.dylib -> /usr/lib/libcharset.1.dylib lrwxr-xr-x 1 jim wheel 25 May 6 07:24 libcharset.dylib -> /usr/lib/libcharset.dylib lrwxr-xr-x 1 jim wheel 29 May 6 05:19 libiconv.2.4.0.dylib -> /usr/lib/libiconv.2.4.0.dylib lrwxr-xr-x 1 jim wheel 25 May 6 05:19 libiconv.2.dylib -> /usr/lib/libiconv.2.dylib lrwxr-xr-x 1 jim wheel 23 May 6 05:19 libiconv.dylib -> /usr/lib/libiconv.dylib

cargo-outdated$ RUSTFLAGS="-L./lib" cargo build --release Compiling libc v0.2.68 ...

I tried making a debug build, so that I could use lldb to get a backtrace. But I discovered that the debug build would not segfault.



D: difficult
Comment Icon19

I've tried both versions:

cargo install --force cargo-outdated --locked


cargo install --force --git https://github.com/kbknapp/cargo-outdated --locked

In both it fails with the same error type:

An attempt to run the command in a verbose mode results in bunch of warnings:

I see that these are the dependencies (direct and indirect) of my project, but I'm not sure why this happens. I have no issues running cargo update or cargo check and judging from docs in README to this repository, cargo-outdated relies on cargo update.



T: bug
Comment Icon7

cargo-outdated is great.. thanks for writing it!

I noticed recently that if my /tmp/ directory contains a Cargo.toml, running cargo outdated fails with a strange error:

(I don't remember why I wound up with a Cargo.toml in /tmp, maybe I moved something there to stash it momentarily).

Is the program maybe using /tmp/ as a working directory, rather than creating a new (empty) tempdir to work from? What other files is it modifying or reading from /tmp/ ?


Find the latest versions by id

v0.11.1 - Apr 16, 2022

v0.11.1 (2022-04-16)

Bug Fixes

  • Update cargo to v0.61.1, git2-curl to v0.15 (215ff0f5, closes #307)

v0.11.0 - Mar 02, 2022

v0.11.0 (2022-03-02)


  • CLI: Adds -e, --ignore-external-rel: Ignore relative dependencies external to workspace and check root dependencies only. (ffbb2493)
  • CLI: uses clap to parse command line (a0a06cdb)

Bug Fixes

  • remove non-json line when run in workspace mode. (9ae14d79, closes #299)
  • 285: Added switch ignore-external-rel to workaround issue 285 (ffbb2493)

v0.10.2 - Nov 17, 2021

Fixes Cargo.lock package version.

v0.10.1 - Nov 16, 2021

v0.10.1 (2021-11-16)

  • Fix acquiring package cache lock (d38926b)

v0.9.17 - Jul 01, 2021


0.9.16 - Jun 26, 2021


v0.9.15 - Apr 26, 2021

0.9.15 release

v0.9.14 - Jan 22, 2021

Update cargo to 0.50, use vendered openssl option for MacOS

v0.9.13 - Oct 29, 2020


v0.9.11 - Jul 19, 2020


v0.9.10 - May 05, 2020

v0.9.9 - Apr 08, 2020

This release adds the ability to respect $CARGO_HOME to build a cache for the dependencies.

v0.9.8 - Mar 25, 2020

v0.9.7 - Mar 05, 2020

v0.9.5 - Feb 18, 2020

This release matches 0.9.5 on crates.io

v0.8.0 - Dec 26, 2018

v0.7.0 - Nov 23, 2017

v0.7.0 (2017-11-23)

Bug Fixes

  • Treats optional dependencies as features as well (closes #100, f67634f)
  • Filters yanked packages out from candidates (closes #101, c42a4ef)
  • Rewrites the algorithm of dependency tree comparison (closes #105, 5cd414a)



  • Adds crates.io version badge to readme (7e64221)
  • Removes dependency graph from readme (3792687)

v0.6.2 - Oct 28, 2017

v0.6.2 (2017-10-28)

Bug Fixes

  • Replaces relative paths with absolute ones in latest manifests (closes #96, ec431cd)

v0.6.1 - Oct 25, 2017

v0.6.1 (2017-10-25)

Bug Fixes

  • Fixes --exit-code, --color (upstream) (closes #63, 4d4b6a8)
  • Calls Source::update() on non-default sources before Registry::query() (closes #91, 9e7b774)


  • Replaces format!() with Path.join() (closes #73, 4d28c02)


  • Runs Travis CI only on master to avoid redundant builds

v0.6.0 - Oct 21, 2017

v0.6.0 (2017-10-21)


  • Queries crates.io API for new versions with a channel-aware policy for latest ones (can be ignored by --aggressive) (closes #75, 7d57929)

Bug Fixes

  • Queries crates.io API for feature changes to avoid "Package does not have these features" errors and warns user of obsolete features (can be suppressed by --quiet) (closes #84, 7d57929)


  • Updates dependency graph in README.md (closes #86, cf773eb)


  • Updates cargo to 0.22.0 (29ce666)

v0.5.3 - Oct 10, 2017

v0.5.3 (2017-10-10)


  • Provides --workspace flag to enforce workspace mode so that it can loop through workspace members even if it's not executed against a virtual manifest (closes #81, f690a7a)

v0.5.2 - Oct 06, 2017

v0.5.2 (2017-10-06)


  • Briefly explains how cargo-outdated works in README.md (8c35c61)


  • Loops through all workspace members if executed against a virtual manifest (closes #58, cd36aed)

Bug Fixes

  • Fixes missing dependency issue for debug build (closes #77, c82e928)


  • Debug build is now part of CI (05ada44)

v0.5.1 - Sep 23, 2017

v0.5.1 (2017-09-23)


  • Fixes a typo (38e37c6, thanks @waywardmonkeys)


  • Enables --all-features by default (closes #57, f24c3a6)
  • Prints a dashed line under the table header (b076bb1, thanks @waywardmonkeys)

Bug Fixes

  • Correctly shows error messages (closes #60, daab865)
  • Excludes default features if not explicitly specified by user (closes #69, 7074fc8)

v0.5.0 - Sep 18, 2017

v0.5.0 (2017-09-18)



  • Replaces RM with Removed (closes #46)
  • Adds Kind, Platform in output


  • Supports cargo workspaces (closes #28)
  • Supports embedded dependencies (fixes #50)
  • Supports build/development/target-specific dependencies (closes #20, fixes #49)
  • Adds --all-features, --features, --no-default-features

v0.3.0 - Dec 06, 2016

v0.3.0 (2016-12-05)


  • adds a --manifest-path and --lockfile-path to allow use with other projects (5f886d27, closes #29)


  • Exit Codes: adds feature for custom exit code on new vers (61c8bb9b, closes #23)


v0.1.3 - Dec 08, 2015

v0.1.3 (2015-11-14)


  • adds demo (c2192aac)
  • updates readme with cargo install instructions (e936a454)

Bug Fixes

  • fixes build error on windows due to upstream dep (af4e1a70)

v0.1.1 - Nov 04, 2015

v0.1.1 (2015-11-04)



  • various fixes from clippy run (b8b633fc)

v0.1.0 - Nov 04, 2015

Information - Updated May 28, 2022

Stars: 833
Forks: 64
Issues: 49


Rust Language Server (RLS)

The RLS provides a server that runs in the background, providing IDEs,

Rust Language Server (RLS)

Rust lang bookmarking tool

Rust and Rocket used bookmarking tool for search bar

Rust lang bookmarking tool

Rust Language Security

execrices: RUSTSEC-2021-0001

Rust Language Security

False Positive for rust-lang/rust#83583

The deprecation lint proc_macro_derive_resolution_fallback is intended to catch proc macro generated code that refers to items from parent modules that should not be in scope:

False Positive for rust-lang/rust#83583

rust_icu: low-level rust language bindings for the ICU library

See: The latest version of this file is available at

rust_icu: low-level rust language bindings for the ICU library

Rust lang exercises

Personal tips and drills in my journey as a beginner rustacean

Rust lang exercises

😍 Rust Language

👍 Download and execute rustup

😍 Rust Language

TensorFlow Rust provides idiomatic Rust language

bindings for Documentation

TensorFlow Rust provides idiomatic Rust language

Rust Language Learning material

Rust is blazingly fast systems programming language that prevents segfaults and guarantees thread safety

Rust Language Learning material
Facebook Instagram Twitter GitHub Dribbble