cargo-nextest runs every Rust test in its own process
A next-generation test runner for Rust.
At a glance
- What is it?
- A Cargo subcommand that replaces the built-in test harness with per-test process isolation, giving you process-level parallelism control, captured output per test and JUnit reporting. The README itself sends you to the website for everything else.
- Who is it for?
- cargo-nextest is the right tool the moment your Rust suite has failures that are hard to read, tests that interfere with each other through global state, or a CI log where a single panic swallows the rest of the output. Running each test in its own process is what buys all three, and it also means the runner cannot share a process-level fixture the way cargo test can, so read the configuration page before migrating a suite that relies on that.
- Can I use it commercially?
- Yes. Apache-2.0 is a permissive licence: you can use, modify and sell software built on it, as long as you keep its copyright and licence notices.
- Is it still maintained?
- Yes. The repository received new commits within the last day.
- What is it written in?
- Mainly Rust, according to GitHub's language statistics.
Answers come from the project's GitHub data, last synced on October 9, 2026, and from our analysis. They are not legal advice.
Editorial analysis
Process isolation as the reason the runner is faster
The repository description is one sentence, a next-generation test runner for Rust, and the README adds that everything else is on the website at nexte.st. That is not a marketing dodge so much as an accurate description of the split: this repository is where the source lives, and nexte.st is where the arguments, the configuration reference and the filterset syntax are explained.
The design decision that matters is that nextest runs each test in its own process rather than as a function call inside one shared binary. cargo test's default harness loads the whole test binary once and calls test functions sequentially or threaded inside it. Anything one test does to global state, to the environment, or to a temp directory is visible to the next one, and a segfault or an abort takes the rest of the run with it.
Process isolation changes that. Each test gets a clean address space, so a crash costs one test rather than the suite, and output is captured per test instead of interleaved on one stream. That per-test capture is what makes the rest of the feature set possible, including the ability to retry a single failing test, to shut down a hanging test after a timeout, and to emit a JUnit report that maps one entry to one test instead of one entry to one binary.
Parallelism also becomes a real dial. Because work is spread across processes rather than threads, the runner can bound how many run at once, which matters on a shared CI machine where an unbounded test suite will happily exhaust cores and memory. The repository topics list flaky-tests and junit, which are the two problems people usually arrive with.
Four crates, two independent version lines
The repository is a Cargo workspace rather than a single crate, and the README enumerates what lives in it. cargo-nextest is the binary you invoke. nextest-runner holds the core logic. nextest-metadata is the library for calling cargo-nextest over the command line, which is what you want if something else in your pipeline needs to start a test run and read its results. nextest-filtering is the parser and evaluator for filtersets.
Each has its own crates.io entry and its own documentation link, and the release history shows the consequence: cargo-nextest-0.9.146 published on 2026-09-21 and nextest-runner-0.124.0 published on 2026-09-16 carry completely different version numbers. They are released on their own schedules, so if you pin the runner library in a tool, you are not pinning the same version you would get by pinning the command.
The workspace membership in Cargo.toml confirms the shape, listing cargo-nextest, fixture-data, integration-tests, internal-test, internal-tools/zstd-dict, nextest-filtering, nextest-metadata, nextest-runner and workspace-hack:
[workspace]
resolver = "2"
members = [
"cargo-nextest",
"nextest-filtering",
"nextest-metadata",
"nextest-runner",
]The fixtures and integration-tests directories in the top-level tree explain why a test runner needs its own integration suite: it runs other people's builds, so it needs sample projects to run against. The jsonschemas directory and the site directory suggest the same project also publishes machine-readable schemas and its own documentation source.
nextest-metadata is the crate to look at first if you are considering this for CI integration rather than for local use, because it is the supported surface for programmatic control rather than shell parsing of human output.
Rust 1.41 to run it, 1.91 to build it
The README draws a distinction that is easy to miss and useful to know. The minimum supported Rust version to run nextest is 1.41, with the honest caveat that nextest is not tested against versions that old and is expected to work with anything released in the past year. The minimum to build nextest from source is 1.91, and for building, at least the last three stable releases are supported.
That gap is the practical takeaway. You can install the binary on an old toolchain, so a pinned CI image stuck on an older Rust does not block adoption. You cannot build it there, which matters if your policy is to vendor binaries from source.
The workspace package table in Cargo.toml agrees with the README and pins the modern end:
rust-version = "1.91"
edition = "2024"
license = "MIT OR Apache-2.0"The stability policy the README links to explains the versioning consequence: while a crate is at 0.x, its minimum supported Rust version may be raised in a patch release, but once a crate reaches 1.x any such bump comes with a new minor version. cargo-nextest is still at 0.9.x, nextest-metadata and nextest-filtering are the crates that would have crossed 1.0, and nextest-runner is at 0.124.0. In practice, a cargo-nextest pin is a pin that can move its own floor.
macOS builds are supported through the MacStadium Open Source Developer Program, which the README credits in its own section. That detail is worth noting for anyone asking about where a project's CI capacity comes from on a platform with expensive runners.
The licence field and the licence files say different things
Two facts about licensing are both true in this repository and they are not the same fact. The repository's own metadata records the licence as Apache-2.0. The README says nextest is available under the terms of either the Apache 2.0 licence or the MIT licence, pointing at LICENSE-APACHE and LICENSE-MIT at the top level. Cargo.toml agrees with the README rather than with the metadata field:
license = "MIT OR Apache-2.0"Both LICENSE-APACHE and LICENSE-MIT exist in the tree, and the README's language about the project being free software provided on an AS IS basis with no warranty matches what you would expect from a dual Apache and MIT grant. Neither single-field reading is enough on its own: a metadata field naming Apache-2.0 describes the most restrictive of the two options rather than the whole grant.
For a reader deciding what they may do, the dual licence is the more useful reading, because it gives you a choice of two permissive grants with no copyleft obligation. The actionable test is to read the two LICENSE files, which are the authoritative text, rather than to rely on any single field.
There is a third licence question worth answering before you copy code out of the tree. The README states the project is derived from diem-devtools, and that upstream source is used under the same Apache 2.0 and MIT terms. So the provenance does not narrow what the dual grant already permits, but it does mean the project carries upstream history rather than having been written from nothing, which matters if you are reading the history to understand why the design is shaped this way.
Configuration errors that tell you which file they came from
The 0.9.145 release is a configuration change rather than a feature, and it addresses something that bites anyone with more than one config file. Diagnostics now name the source file for each setting: cargo nextest show-config version shows which file specified the nextest-version requirement, and cargo nextest show-config test-groups shows which file each override was defined in.
That sounds small until you have a repository-level .config/nextest.toml, a tool-specific config file, and a profile inheritance chain. The same release notes say that per-test overrides and setup and wrapper scripts defined in a profile's inheritance chain are now applied at all, where previously only the selected profile's own overrides and those in profile.default were consulted. That is a correctness fix: an override written in an intermediate profile was being silently ignored.
The same notes also make config paths behave like other command line tools. Paths in errors and warnings are now shown relative to the directory nextest is invoked from, where parse errors used to show absolute paths and warnings used to show paths relative to the workspace root, and in stylized output those paths are colored. Inconsistent path bases in two kinds of message is exactly the kind of thing that costs an afternoon when you are reading a CI log.
Both changes came with issue references, which suggests they came from reports rather than from a design pass. The config file itself preserves key order, which the Cargo.toml workspace dependencies explain by enabling the preserve_order feature of the config crate, and that ordering matters because setup scripts run in the order they are written.
The newest release, cargo-nextest-0.9.146 on 2026-09-21, is a single-line dependency fix updating chacha20 and der to non-yanked versions, which is the normal shape of a security-driven patch release in a crate with a wide dependency tree.
What this repository does not tell you
The README is a pointer, not a manual, and that is the honest shape of the project. It names the crates, states the minimum Rust versions, points at the stability policy, lists two licences, credits the MacStadium program, and sends you to nexte.st for everything else. There are no install commands in it, no configuration example and no filterset example.
So the questions that decide adoption are all answered elsewhere. Whether nextest can run your particular test, meaning whether the test uses APIs the process model cannot support, is a website question. How filtersets select by platform, architecture or dependency is a website question, and the README links nextest-filtering's documentation specifically for filterset syntax. Which default-failure behaviour and retry policies exist is a configuration reference question.
The repository itself is still worth reading for a different reason. AGENTS.md and CLAUDE.md at the top level, a Justfile, Cross.toml for cross-compilation targets, a .git-blame-ignore-revs file and zizmor.yml for a supply-chain linter describe how the maintainers work on the code. The jsonschemas directory suggests configuration can be validated by an editor, which is more useful day to day than any single feature.
The last push was on 2026-09-23, the day after the newest release, with 103 open issues on 3,299 stars. The open question count is worth a moment's attention before you plan a migration, because a suite that depends on runner behaviour needs its issue tracker watched during the change rather than after it.
Editorial conclusion
cargo-nextest is the right tool the moment your Rust suite has failures that are hard to read, tests that interfere with each other through global state, or a CI log where a single panic swallows the rest of the output. Running each test in its own process is what buys all three, and it also means the runner cannot share a process-level fixture the way cargo test can, so read the configuration page before migrating a suite that relies on that. Two facts to settle first: the repository's own metadata records the licence as Apache-2.0 while the README and Cargo.toml both offer MIT or Apache-2.0, so treat the dual licence in the repository files as authoritative. And the README contains no installation commands at all, so get the binary from the release page at nexte.st rather than guessing at a cargo install line.
Frequently asked questions
What does nextest do?
nextest is a Cargo subcommand, published as cargo-nextest, that replaces the built-in Rust test harness. It runs each test in its own process, which lets it capture output per test, bound parallelism at the process level and report one result entry per test.
What is the difference between cargo nextest and cargo test?
cargo test runs tests as function calls inside one shared test binary, so global state, environment changes and crashes can leak between tests. cargo-nextest runs each test in its own process, which isolates failures and enables per-test output, process-level parallelism control and JUnit reports, at the cost of not sharing a single process-level fixture.
What is the minimum Rust version needed for cargo-nextest?
Running nextest needs Rust 1.41, and the README notes it is not tested against versions that old but should work with anything from the past year. Building nextest from source needs Rust 1.91, with the last three stable releases supported.
Which crates does the nextest repository publish?
Four: cargo-nextest, the binary, nextest-runner for core logic, nextest-metadata for calling cargo-nextest over the command line, and nextest-filtering for parsing and evaluating filtersets. They are versioned and released independently, so a pin on one does not pin the others.
Official sources
Add this badge to your README
If you maintain this project, the badge below links readers to this analysis and shows its maintenance status from the daily GitHub snapshot. Paste the markdown into your README; add ?metric=license or ?metric=stars to the image URL for a different field.
[](https://hysenlabs.com/projects/nextest-rs-nextest)