54 releases (breaking)

0.41.0 Jul 3, 2024
0.39.0 Oct 23, 2023
0.37.0 Jun 3, 2023
0.36.0 Feb 20, 2023
0.2.5 Jul 28, 2017

#13 in Development tools

Download history 17115/week @ 2024-03-29 17116/week @ 2024-04-05 17309/week @ 2024-04-12 17964/week @ 2024-04-19 19196/week @ 2024-04-26 15677/week @ 2024-05-03 18066/week @ 2024-05-10 16631/week @ 2024-05-17 13815/week @ 2024-05-24 19088/week @ 2024-05-31 16312/week @ 2024-06-07 15848/week @ 2024-06-14 21448/week @ 2024-06-21 19129/week @ 2024-06-28 15722/week @ 2024-07-05 12875/week @ 2024-07-12

72,398 downloads per month
Used in 77 crates (72 directly)

MIT license

3.5K SLoC


Build status Build Status crates.io:clin docs

self_update provides updaters for updating rust executables in-place from various release distribution backends.


Update (replace) the current executable with the latest release downloaded from https://api.github.com/repos/jaemk/self_update/releases/latest. Note, the trust project provides a nice setup for producing release-builds via CI (travis/appveyor).


The following cargo features are available (but disabled by default):

  • archive-tar: Support for tar archive format;
  • archive-zip: Support for zip archive format;
  • compression-flate2: Support for gzip compression;
  • compression-zip-deflate: Support for zip's deflate compression format;
  • compression-zip-bzip2: Support for zip's bzip2 compression format;
  • rustls: Use pure rust TLS implementation for network requests. This feature does not support 32bit macOS;
  • signatures: Use zipsign to verify .zip and .tar.gz artifacts. Artifacts are assumed to have been signed using zipsign.

Please activate the feature(s) needed by your release files.


Run the following example to see self_update in action:

cargo run --example github --features "archive-tar archive-zip compression-flate2 compression-zip-deflate".

There's also an equivalent example for gitlab:

cargo run --example gitlab --features "archive-tar archive-zip compression-flate2 compression-zip-deflate".

which runs something roughly equivalent to:

use self_update::cargo_crate_version;

fn update() -> Result<(), Box<::std::error::Error>> {
    let status = self_update::backends::github::Update::configure()
    println!("Update status: `{}`!", status.version());

Amazon S3, Google GCS, and DigitalOcean Spaces are also supported through the S3 backend to check for new releases. Provided a bucket_name and asset_prefix string, self_update will look up all matching files using the following format as a convention for the filenames: [directory/]<asset name>-<semver>-<platform/target>.<extension>. Leading directories will be stripped from the file name allowing the use of subdirectories in the S3 bucket, and any file not matching the format, or not matching the provided prefix string, will be ignored.

use self_update::cargo_crate_version;

fn update() -> Result<(), Box<::std::error::Error>> {
    let status = self_update::backends::s3::Update::configure()
    println!("S3 Update status: `{}`!", status.version());

Separate utilities are also exposed (NOTE: the following example requires the archive-tar feature, see the features section above). The self_replace crate is re-exported for convenience:

fn update() -> Result<(), Box<::std::error::Error>> {
    let releases = self_update::backends::github::ReleaseList::configure()
    println!("found releases:");
    println!("{:#?}\n", releases);

    // get the first available release
    let asset = releases[0]

    let tmp_dir = tempfile::Builder::new()
    let tmp_tarball_path = tmp_dir.path().join(&asset.name);
    let tmp_tarball = ::std::fs::File::open(&tmp_tarball_path)?;

        .set_header(reqwest::header::ACCEPT, "application/octet-stream".parse()?)

    let bin_name = std::path::PathBuf::from("self_update_bin");
        .extract_file(&tmp_dir.path(), &bin_name)?;

    let new_exe = tmp_dir.path().join(bin_name);


License: MIT


~439K SLoC