goose is a Locust shaped load tester written in Rust, and the dashboard is a compile time feature

The load test is a Rust program, which is the whole design

goose is a load testing framework inspired by Locust, developed by Tag1 Consulting, and the first thing to understand is the shape of the artefact.

To use goose, you write a Rust application using the Goose library. Then you compile it to create a tailored load testing tool specific to your needs.

That is a different contract from Locust, where the test is a Python file the framework runs. Here the test is a binary, so the things that make Rust good at this apply: the client is a compiled HTTP stack, the concurrency model is tokio, and the load generator can be a real program with real logic.

The reasons the project gives are consistent with that. It is fast and scalable, built with Rust, designed for speed and scalability. It is flexible and customizable, supporting simple and complex load tests tailored to mimic real-world user behavior. And it does realistic user behavior simulation, going beyond just sending requests to simulate behaviors like logging in, filling out forms and navigating through the application.

That last one is the part that separates a load tester from a request generator. A tool that sends N requests per second tells you very little, because real traffic has a shape: a user logs in, then browses, then submits. Goose models the journey and the concurrency follows the users, not the request rate.

The homepage is tag1.com/goose, the documentation is at book.goose.rs with the API reference on docs.rs, and the licence is Apache-2.0. The recent releases are 0.18.1 from 2025-08-14, 0.18.0 from 2025-02-25 and 0.17.2 from 2023-08-28, with the manifest version at 0.19.0-dev and the last push to the repository on 2026-10-15.

The dashboard is behind a feature flag, and that is a deployment decision

The live dashboard is the most distinctive feature in the README, and it is opt-in in two separate ways.

Compile with `--features dashboard`, run with `--dashboard`. The web UI streams live metrics, RPS, users and latency charts, over SSE while a test runs. Optional authenticated control lets you Start, Stop and set target users from the browser.

Both halves of the opt-in matter. The feature flag means the dashboard code is not compiled into a normal load test binary, so a production load generator carries no web server, no SSE endpoint and no authentication code. The `--dashboard` flag then means the server is not started even in a binary that could serve it.

That is a sensible design for a tool that often runs in a container on a load generator in a data centre, where an open dashboard endpoint would be an unwelcome liability. The authenticated control is what makes it usable for a team, since it means the person watching can start and stop the test rather than needing shell access to the generator.

The Cargo manifest shows the cost of the feature. The dashboard pulls in `axum` for the server, `hyper` and `hyper-util` for the HTTP layer, `tower-http` for the header middleware, and `tokio-tungstenite` for the WebSocket support, all marked optional. The headless browser support is separate again, with `headless_chrome` and `urlencoding` as optional dependencies, and the `fetch` feature enabled on it.

So a default build of goose is a load generator with no web server and no browser. A build with the dashboard has a web server. A build with browser support can drive a real browser, which is how you test a single page application that will not respond to a synthetic HTTP client.

The documentation points at a specific page in the Goose Book for the Live Dashboard, and the flags are `--features dashboard`, `--dashboard` and `--dashboard-control`, with the last one being the authenticated control.

The dependency list shows what a load generator actually needs

The manifest is a good map of the implementation, and it is a conventional Rust async stack.

The HTTP client is `reqwest` at 0.13 with the default-tls, form, gzip and json features, and the `http` crate at 1.1 for the types. The runtime is `tokio` with the fs, io-util, macros, net, rt-multi-thread, time and sync features, so it is the full multi-threaded runtime rather than a current-thread one, which is what you want when the point is to saturate a network connection.

Serialisation is `serde` with derive, plus `serde_json`. Configuration and logging are `gumdrop` for the command line options, `simplelog` for the log setup, and `log` underneath. `ctrlc` at 3 is the signal handling, which is how a load test shuts down cleanly when you press Ctrl+C rather than losing the metrics.

The rest are the ones worth noting. `flume` is the channel implementation, `itertools` for the combinators, `rand` at 0.9 for the randomised parts of a simulated user journey, `regex` for matching responses, `chrono` with serde for timestamps, `downcast-rs` for the metric aggregation, `strum` and `strum_macros` for the enum iteration that a metric registry needs, and `num-format` for human readable numbers in the reports.

`futures` at 0.3 is the async combinator library, and `lazy_static` is still there at 1.4, which is a leftover from older Rust idioms.

The default feature set is just `cookies`, and the comment explains why: cookies are included by default for backward compatibility and expected behavior in web load testing. That is a small thing with a real effect, since a load test that drops session cookies will log every user out and measure a completely different application from the one you meant to measure.

The TLS story is worth noting too. There is a `rustls-tls` feature, and the comment says reqwest 0.13 and later already defaults to rustls, so the feature is about the WebSocket client's TLS rather than the HTTP client.

The examples show the feature surface, and Goose Eggs helps

The examples directory is the fastest way to see what the framework can do, and the names tell you the range.

There is `simple.rs` for the basic case, `session.rs` for a session-based flow, `basic_auth.rs` for authentication, and `closure.rs`, which is a Rust-specific demonstration of how you capture state between requests using closures. Then there are the ones that go beyond plain HTTP: `graphql_loadtest.rs` for a GraphQL endpoint, `tcp_loadtest.rs` for raw TCP rather than HTTP, `drupal_memcache.rs` for a specific application pattern, and a `umami/` directory for an analytics service.

The `closure.rs` example is the one that shows the Locust-inspired design most clearly. In a Python load test you would store a token in a variable between requests; in Rust, where the test is compiled, the idiomatic way to carry state is a closure, and the framework has to support that pattern for the design to feel natural.

For common tasks there is a companion crate, Goose Eggs, which provides useful functions for writing load tests, such as validation helpers for HTTP responses. That is a good sign about the project's health, because a framework that needs its own ecosystem of helper crates has users who are building real test suites rather than evaluating the tool once.

The documentation set is layered. The Goose Book is a comprehensive guide to getting started, the developer documentation on docs.rs has detailed API information and tutorials, and the project maintains a Discord community, a series of blog posts and podcasts detailing its features, comparisons with other tools, and real-life testing scenarios.

The repository root also has a `context7.json` file, which is the machine readable context format used by the Context7 documentation service, and a `memory-bank/` directory, plus a `.clinerules` file. The examples, the tests and the `src/` directory make up the rest.

A load tester is a dangerous tool, and the licence says so

There is one point that belongs in any evaluation of a load testing framework, and it is not a technical one.

A load testing tool is a tool for putting a server under more traffic than it is designed for. Run against the wrong host, at the wrong rate, it is an outage. The recent history of load testing tools includes a number of well publicised incidents caused by load generators pointed at production services they were not supposed to be testing.

The README does not address this directly, and that is worth noticing in a framework aimed at simulating realistic user behavior against real applications. What it does say is that the tool is for identifying performance bottlenecks, optimizing resource allocation and ensuring a seamless user experience, which is the legitimate use.

The technical features that make misuse easier are the same ones that make the tool good. Simulating login flows and form filling means generating genuine session state. The optional headless browser support means you can drive a real browser, which is the only way to load a single page application, and it is also the most expensive way to generate load. The `cookie` default means the tool maintains real sessions. And a compiled binary running on a machine with many cores will generate far more load than a script would.

So the operational checklist for adopting goose is worth stating plainly. Confirm the authorisation for the target in writing before you run anything, and confirm the rate is bounded by something other than the machine's core count. Use the compiled metrics rather than eyeballing, because the framework measures and the tool will happily tell you it was generating two thousand requests a second. And keep the generated traffic off production paths where a mistake would be visible to customers.

The licence is Apache-2.0, so the tool itself is free to use, and the project is maintained by a consultancy that publishes blog posts and podcasts about it, which means there is a body of published practice to read before you write your first scenario.

Editorial conclusion

Adopt goose if your team writes Rust and you want a load test that is a normal Rust program rather than a configuration file interpreted by someone else's runtime, and you are comfortable giving a load generator real CPU. Do not adopt it if your team does not write Rust, because the test is compiled as a Rust application, and do not expect the dashboard to be present by default, since it is behind a feature flag. Verify first that the release you take has the dashboard support you need, that the metrics you rely on are collected the way you expect, and that the load you plan to generate is authorised for the target, because a load tester pointed at the wrong host is an incident.

Frequently asked questions

Official sources

1. License: Apache-2.0
2. Project website
3. README
4. Releases
5. tag1consulting/goose on GitHub