hurry!

Really, really fast builds.

Usage

The quickest way to get started with Hurry is to use our managed build cache. To start, you'll need to sign up for an account at hurry.build to get your HURRY_API_TOKEN. Then, run:

# Instead of `cargo build`:
$ HURRY_API_TOKEN=your_token_here hurry cargo build

Alternatively, you can self-host Hurry locally or on your own infrastructure.

Installation

Unix (macOS/Linux)

curl -sSfL https://hurry.build/install.sh | bash

You can configure certain installer options:

# Install to a specific directory (defaults to ~/.local/bin)
curl -sSfL https://hurry.build/install.sh | bash -s -- -b /usr/local/bin

# Install a specific version
curl -sSfL https://hurry.build/install.sh | bash -s -- -v 0.2.0

# Get help
curl -sSfL https://hurry.build/install.sh | bash -s -- -h

Windows

irm https://hurry.build/install.ps1 | iex

You can configure certain installer options:

# Install a specific version
$env:Version="0.2.0"; irm https://hurry.build/install.ps1 | iex

# Install to a custom directory (defaults to $env:LOCALAPPDATA\Programs\hurry)
$env:BinDir="C:\Tools"; irm https://hurry.build/install.ps1 | iex

# Show help
$env:Help="true"; irm https://hurry.build/install.ps1 | iex

Manual

Download the latest release for your platform from GitHub Releases, extract the archive, and place the hurry binary in your PATH.

How does it work?

Hurry works by examining the build plan generated by Cargo, seeing if any of the necessary artifacts are restorable from remote cache, and downloading them into your target folder if they're available. It then runs the build and uploads any missing artifacts to the remote cache.

Known limitations

Hurry is currently in alpha, and there are many rough edges. Some current known limitations include:

• Limited, experimental support for cross-compilation.
• No build acceleration support for cargo commands other than cargo build (e.g. cargo run, cargo test, cargo install).
• No build acceleration support in Windows.
• No build acceleration support for dependencies that are not public crates from crates.io.
• No build acceleration support for first-party packages.
• Limited, experimental support for build scripts that link against native libraries.
• Hardcoded paths (e.g. in stack traces or panics) may use the path where the cached unit was compiled instead of the path where the unit is being built.

We are currently working on resolving all of these limitations. If any of them are a blocker for your team's adoption of Hurry, please reach out to us and we can help prioritize your rollout.

Supported platforms

Like Cargo, Hurry supports a wide range of platforms using a target tier policy. The supported platforms are:

Tier 1 support

Hurry provides Tier 1 support for 2 platforms:

• aarch64-apple-darwin
• x86_64-unknown-linux-gnu

These platforms have full support for build acceleration and distributed caching.

Tier 2 support

Hurry provides Tier 2 support for 3 platforms:

• aarch64-unknown-linux-gnu
• x86_64-unknown-linux-musl
• aarch64-unknown-linux-musl

Platforms in Tier 2 have unstable support for build acceleration and distributed caching. We intend to support build acceleration on these platforms, and we have automate testing coverage over them, but we do not exercise their hot paths as extensively as Tier 1 platforms, so their support may be less stable.

Tier 3 support

Hurry provides Tier 3 support for 1 platform:

• x86_64-pc-windows-gnu

Platforms in Tier 3 have automated testing and precompiled binaries, but their subcommands may not be accelerated. For example, hurry cargo build on Windows will directly pass through to cargo build, and does not implement any distributed caching.

The intent of Tier 3 platforms is to help your team migrate your build processes to hurry more easily. Even in platforms where hurry does not yet support build acceleration, you can still replace all instances of cargo build with hurry cargo build, and your build should still behave the same as before.

License

Hurry is licensed under the Apache 2.0 License.