cargo-wizard: three opinionated Cargo profiles instead of hunting through the perf book

What it does: write profile and RUSTFLAGS settings into two files

cargo-wizard is a Cargo subcommand that applies profile and config templates to your Cargo project to configure it for maximum performance, fast compile times or minimal binary size. The mechanics are narrow and worth being precise about. The tool can create or modify Cargo profiles in your Cargo.toml manifest and RUSTFLAGS in the .cargo/config.toml file, based on a set of predefined templates. That is the whole scope, and the README is direct about it: cargo-wizard currently only modifies Cargo.toml and config.toml, there are other things that can be configured to achieve even smaller binaries, but these are out of scope for this tool, at least at the moment. The primary language is Rust, the licence is MIT, the version is 0.2.3 with a release of the same number on 2026-04-13, and the last push to the repository was on 2026-07-25.

The motivation: the same configuration question, asked on every new project

The Motivation section explains why the tool exists in terms of repeated work rather than deep complexity. The author often sees Rust users asking online about how to configure Cargo for the fastest compilation times, the best runtime performance or the minimal binary size. The information can be found in various books, repositories or blog posts, and the complaint is that it is annoying to hunt for it every time you want to configure a new Cargo project. So the tool automates that process. The consequence for an adopter is that the templates are a starting point rather than an authority, and the README is explicit that the tool mostly serves to improve discoverability of possible Cargo profile and config options, to help you find the ideal settings for your use cases. The two things it credits are the Rust Performance Book and the min-sized-rust repository.

Three templates, and what each one actually changes

The templates are named for the outcome. fast-compile minimizes compilation times, and it disables debuginfo generation and uses a faster linker, and in nightly mode it also enables the Cranelift codegen backend and the parallel frontend. fast-runtime maximizes runtime performance, and it enables LTO and other settings designed for that goal. min-size minimizes binary size, and it is similar to fast-runtime but uses optimization flags designed for small binary size rather than for speed. The structure of the three is instructive, because the two later templates share a base and differ only in the optimisation flags, which tells you that the difference between a fast binary and a small one is a flag choice rather than a different build system. You can also modify the templates in the interactive mode to build your own custom template, so the three are entry points rather than a closed set.

Two ways to run it, and the nightly requirement

There are two modes. Interactive mode is a CLI dialog that guides you through the process, invoked as cargo wizard, and the name is explained in the Inspiration section as coming from GUI wizards that guide you through a process using a series of dialogs. Non-interactive mode applies a predefined template directly to your Cargo workspace, invoked as cargo wizard apply with a template and a profile, for example cargo wizard apply fast-runtime dist to apply the fast-runtime template to the dist profile. The interactive mode is where the template editing happens, so the two modes are for different jobs. The nightly features are a separate axis: you can enable additional configuration options that require a nightly compiler by running cargo-wizard with a nightly Cargo, for example cargo +nightly wizard, or by using the --nightly flag. That is what gates Cranelift and the parallel frontend.

$ cargo install cargo-wizard
$ cargo wizard
$ cargo wizard apply fast-runtime dist

The workspace requirement, and the RUSTFLAGS workaround

Two constraints deserve attention because they change how you invoke the tool. First, you should be executing cargo wizard inside a directory that is a part of a Cargo workspace, since it applies the configuration options to that workspace. Second, and more consequentially, Cargo config changes are applied to the global build.hostflags setting, because per-profile RUSTFLAGS are still unstable, with a link to the tracking issue in the Cargo repository. The consequence is real and it is not flagged as loudly as it could be. A profile is supposed to carry its own flags, so a debug build and a release build can have different optimisation and debuginfo settings. Applying the flags globally means they apply to every profile in the workspace, including the ones the tool did not target. If you have a debug profile you have deliberately configured, that configuration is what the global hostflags will override.

The caveats section, which is the honest part of the README

There is a Caveats section with four items, and they are worth quoting in summary. The configuration applied by the tool is quite opinionated and might not fit all use cases perfectly, and the tool mostly serves to improve discoverability. The tool currently only modifies Cargo.toml and config.toml, with other approaches to smaller binaries out of scope for now. The tool currently ignores Cargo settings that are not relevant to performance. And the config.toml changes are applied to the global build.hostflags setting because per-profile RUSTFLAGS are still unstable. The third caveat deserves a second look from anyone whose build is not a simple case, because a tool that ignores settings it considers irrelevant can quietly discard configuration you cared about, and a reader should know that before they run it on a workspace with hand-tuned settings.

The dependency choices, and what the manifest does not include

The Cargo.toml shows the shape of the tool and explains one decision in the acknowledgements. toml_edit is credited as an awesome crate that can modify TOML files while keeping their original formatting, and that choice is what lets the tool rewrite a Cargo.toml without reformatting the whole file, which matters because a manifest a developer hand-wrote should not come back reformatted. inquire is credited as a pretty slick crate for building interactive TUI dialogs and prompts, which is the interactive mode. Other dependencies include cargo_metadata to inspect the workspace, clap with the derive feature for the command line, rustc_version to detect the compiler, similar with the inline feature for diffing, and console with windows-console-colors for terminal output. The include list is only src/**/*.rs, Cargo.toml and README.md, and the dev dependencies include insta for snapshot testing and, on Linux only, rexpect for driving the interactive prompts in tests.

The roadmap, and what a 0.2 version means

The Contributing section lists possible future features, and both are things a Rust build engineer would want. One is to allow configuring the memory allocator, which is a well known lever for both binary size and runtime performance, and the other is to load and store templates on disk to make them easier to share. Sharing is the more interesting of the two, because the templates are opinionated by nature and a team that has tuned one for their own constraints currently has no way to hand it to a colleague. The version number is 0.2.3 and the package is categorised as a development-tools cargo plugin, with edition 2024. The release history in the repository shows one listed release, v0.2.3 from 2026-04-13, and the repository is not archived, with the last push on 2026-07-25. For a tool that rewrites your build configuration, a version number under one and a recent single release are the two facts to weigh before pointing it at a workspace you care about.

Editorial conclusion

cargo-wizard suits a Rust developer setting up a new project who knows the settings exist but does not want to spend an afternoon assembling them, and who wants the answer written into the manifest in a form a colleague can read. It is the wrong tool when you already know your build configuration, since the templates are opinionated and the README says so, and a poor fit if you need per-profile RUSTFLAGS, because those are still unstable in Cargo and the tool therefore applies the flags globally through build.hostflags. Before running it, read the Caveats section, and note that you must run cargo wizard from inside a Cargo workspace, since the configuration is applied to that workspace.

Frequently asked questions

Official sources

1. Issues
2. Kobzol/cargo-wizard on GitHub
3. License: MIT
4. README
5. Releases