Goose is a load testing framework written in Rust and inspired by Locust, aimed at developers and performance engineers who want to define realistic user behavior in code and compile it into a load testing tool of their own.

What it is

Goose is an open-source load testing library rather than a finished application. A team writes a Rust program against the Goose library, describes the traffic it wants to generate, and compiles that program into a purpose-built load testing tool. The project is developed by Tag1 Consulting, lives in the Infrastructure and Operations / Monitoring and Observability category, and is published as the goose crate on crates.io under the Apache-2.0 licence. Supporting documentation is split between The Goose Book at book.goose.rs and API documentation at docs.rs/goose.

The concrete problem it solves is that generic load generators force a trade-off between realism and control. A test that only fires requests at endpoints does not capture a session in which a user logs in, fills out a form, and then navigates through the application. Goose lets the test itself be ordinary Rust code, so the sequence of user actions, the branching between them, and any validation of the responses can all be expressed directly and then compiled into a binary that targets the application under test. It replaces the practice of bending a general-purpose testing tool into shapes it was not built for, and it sits in the same space as the Locust project whose approach inspired it.

Key capabilities

• Load tests are written as a Rust application and compiled, producing a tailored testing tool rather than a configuration file interpreted at runtime.
• HTTP load testing is a first-class concern, reflected by the http and http-client topics and by HTTP response handling in the library.
• User behavior is simulated as a journey: logging in, filling out forms, and navigating through an application, not merely as isolated requests.
• Metrics and performance measurement are part of the core feature set, matching the metrics and performance topics.
• The goose-eggs helper crate supplies utility functions for writing load tests, including validation helpers for HTTP responses.
• A collection of ready-made examples lives in the examples/ directory of the tag1consulting/goose repository on GitHub.
• The Goose Book and the docs.rs API reference provide the guided path from first test to complex scenario.

Who uses it and how

• Engineering teams that need to reproduce real traffic patterns before a launch or a known high-traffic event, using sessions rather than single requests.
• Rust shops that prefer to keep load tests in the same language and toolchain as the services they are testing.
• Teams that need to assert on responses during a load run, which is where the goose-eggs validation helpers apply.
• Projects that want a compiled, self-contained load testing binary rather than a script executed by an interpreter.

Getting started

Add the goose crate from crates.io to a Rust project, write the load test, and compile it into a custom tool; The Goose Book at book.goose.rs covers the setup, and the examples/ directory in the repository provides working starting points.

How it compares

No list of paid products it replaces is given in the facts, so the only named comparable is Locust, the project whose design inspired Goose. Goose takes that inspiration and delivers it as a Rust library that is compiled into a bespoke testing tool, with the Apache-2.0 licence and the crate on crates.io as the distribution path.

When to use it — and when not to

A self-hoster must run a Rust toolchain and compile a binary, and no packaged Docker image, Compose file, or hosted option is described in the README, so anyone wanting a point-and-click or configuration-driven load tester should look elsewhere. The README is deliberately short and defers heavily to The Goose Book and the API documentation, so teams that need everything explained in the repository itself will have extra reading to do. The project is active, with a recent push, but the repository carries a substantial number of open issues, so a team should expect to work with an evolving codebase rather than a frozen one.