Fleet, a Rust build tool that wraps cargo with sccache, lld and ramdisks

A cache and linker strategy rather than a new compiler

Fleet is a build tool for Rust, and the README claims compiling with it is up to five times faster than with `cargo`. The mechanism it describes is not a new compiler. It optimizes builds by using tooling already present in the Rust ecosystem: sccache for caching, lld and zld for linking, and ramdisks for people on WSL or spinning disks.

That list is the entire architecture, and it is worth pausing on what it implies. Every claim about speed rests on an external component doing the work. If your rebuilds are slow because crates are recompiled from scratch, sccache is the part that helps. If they are slow because linking dominates, the linker choice matters. If they are slow because the filesystem is slow, the ramdisk does. Fleet's contribution is choosing those for you and wiring them into a `cargo`-compatible entry point.

The install paths match that design. On macOS and Linux:

curl -L get.fleet.rs | sh

On Windows:

iwr -useb windows.fleet.rs | iex

Both of those pipe a script straight into a shell, which is the current default for Rust tool installers and also the reason to read the script before running it if your organization's policy says so.

Building from source needs Rust as the only prerequisite:

cargo install --git https://github.com/dimensionhq/fleet fleet-rs

The manifest ships two binaries and about two dozen dependencies

The `Cargo.toml` names the package `fleet-rs` and builds two executables from the same entry point:

[[bin]]
name = "cargo-fleet"
path = "src/main.rs"

[[bin]]
name = "fleet"
path = "src/../src/main.rs"

The `cargo-fleet` name is what makes it callable as a cargo subcommand, which is how a build tool slots into an existing workflow without changing your commands. The second binary, `fleet`, is the standalone form. Both point at `src/main.rs`.

The dependency list is long for a tool that mostly configures other tools: `anyhow` and `thiserror`-style error handling, `ansi_term` and `colored` for terminal output, `comfy-table` for tables, `indicatif` for progress bars, `dialoguer` for interactive prompts, `human-panic` for readable crash output, `ptree` for a process tree view, `sysinfo` and `sys-info`, `dirs`, `which`, `byte-unit`, `cargo-util`, `rustc_version`, `wsl`, `serde`, `serde_json`, `toml` with `preserve_order`, `uuid` and `clap` configured with the cargo feature. `clap` with the cargo feature is how it forwards arguments to the underlying build command.

Two of those are worth a note. `rustc_version` as a build dependency means the tool queries the compiler version at build time, which suggests version-dependent behaviour. `wsl` means the Windows binary has specific knowledge of the WSL environment, which matches the ramdisk claim in the README.

The repository layout is small: `src/`, `installer/`, a `fleet.toml` at the root, plus `Cargo.lock`, `todo.md` and the usual files. A `fleet.toml` at the root implies per-project configuration, which is the file you would expect a project to commit if it wants its build settings to travel with the code.

Two version numbers and two GitHub owners, both unresolved

The repository facts and the README do not fully agree, and in a build tool those disagreements matter more than they would in a library.

The first is the version. The README carries a badge reading `version-1.0.0--beta`, while the manifest declares:

[package]
name = "fleet-rs"
version = "0.0.8"
edition = "2021"

So the badge advertises a 1.0.0 beta and the build itself identifies as 0.0.8. Nothing in the repository explains which is authoritative. The manifest is what a package manager reads and what determines what you actually install, so treat 0.0.8 as the real number and the badge as aspirational or stale.

The second is ownership. The repository under review is `suptejas/fleet`, but nearly every link in the README points at `dimensionhq/fleet`: the issue tracker, the tags page, the source checkout in the build-from-source command, the license badge, and even the description field in the manifest. The homepage is `fleet.rs` in both cases.

Both facts can be true at once, and the likely explanation is a fork or a mirror: someone republished the project under a different account and updated some fields but not all. The README's own links would still send you to the original. For a build tool that inserts itself between you and the compiler, that is a reasonable thing to establish before adopting it, because you want to know which repository you are reading documentation from and which one you are running. There is no commit message or README section that resolves it.

Practically, the test is cheap: install it, run `fleet --version` and see whether the number agrees with the manifest, and check whether the binary you have reports the upstream identity. The README gives no output to compare against, which is itself the gap.

What the README promises about speed and what it declines to promise

The speed claim is specific in form and unbacked in detail. Up to five times faster than `cargo` is a number, and the word up to does real work in that sentence: it is a ceiling rather than an expectation. The README publishes no benchmark, no input project and no methodology, so the figure cannot be reproduced from the documentation. Whether your build gets five times faster, two times faster or none depends entirely on whether sccache is cold or warm.

A cold cache, which is your first build after cloning, has nothing to hit. A warm cache after a branch switch is where a compiler cache pays. If you rebuild the same dependencies many times a day, that is the case the tool targets. If you build once and then spend the day writing code without recompiling, you will notice very little.

What the README does state plainly is the stability position. It says that since Fleet is still under development, it might not be completely stable yet, and points at the issue tracker for bug reports. A tool that wraps your compiler is a bad place to be conservative about that warning, because a mistake does not fail loudly, it produces a stale binary.

On versioning, the README says the project uses SemVer and directs you to the repository tags for what exists. That guidance is thin given the two conflicting version numbers. The project publishes no GitHub releases at all, so there is no changelog, no upgrade note and no compatibility statement between versions. You find out what changed by reading commits.

Where Fleet sits against cargo build settings and a plain sccache setup

There are two serious alternatives, and the honest comparison depends on how much of Fleet you actually need.

The first is configuring cargo and sccache yourself. Cargo already supports incremental compilation and parallel jobs, and sccache can be installed on its own and used through `RUSTC_WRAPPER`. Since sccache is the component doing most of the work Fleet claims, a manual setup of a cache wrapper plus a linker flag gets you most of the benefit with none of the extra binary in the path. What you give up is the automatic detection of which linker is fastest on your platform and the ramdisk handling.

The second is doing nothing about the toolchain and fixing the real cost. On WSL and on machines with slow disks, the bottleneck is frequently filesystem access to the target directory. Fleet's ramdisk answer is a genuine one in that situation, and it is the feature least likely to be something you would assemble yourself. The `wsl` dependency in the manifest suggests this case was thought about specifically.

The practical test before adopting: measure what a rebuild costs on your machine before and after. `cargo build` timings are easy to capture and the answer decides the case. If most of your rebuild time is linker time and your disk is slow, Fleet has something specific to offer. If your builds are already fast because the project is small, adding a wrapper between you and cargo buys very little and costs a layer of debugging when something goes wrong.

Editorial conclusion

Fleet makes most sense for a Rust developer whose rebuilds are dominated by recompiling unchanged dependencies, where a compiler cache pays for itself immediately, and for Windows or WSL users whose disk latency is the bottleneck the ramdisk feature targets. It is a poor choice if you build once and deploy, or if you need guarantees the README cannot give, since it states outright that the project might not be completely stable yet. Before trusting it, resolve the version discrepancy: the README badge advertises 1.0.0-beta while `Cargo.toml` says 0.0.8. The last push was on 2026-04-22 and the project publishes no GitHub releases, so the repository history is the only change log.

Frequently asked questions

Official sources

1. Issues
2. License: Apache-2.0
3. Project website
4. README
5. suptejas/fleet on GitHub