Wolverine: a .NET mediator and message bus from JasperFx

The problem Wolverine targets in .NET server side code

Most .NET services end up with two overlapping pieces of plumbing: an in-process dispatcher that routes a request to a handler, and a message bus that moves work between processes. Teams usually pick separate libraries for each and then write the glue. Wolverine's stated position is to be both at once, described in the README as a "Next Generation .NET Mediator and Message Bus". The intended audience is .NET developers building server side applications, particularly those who combine it with Marten, which the README calls the "critter stack" for server side development in .NET. That pairing matters: the project's history section says Wolverine was rebooted in 2022 with the explicit intention of being combined with Marten. If you are not working in .NET, or your handlers are short lived request/response endpoints with no cross-process messaging, the mediator side alone is a thin reason to take on the dependency.

How the code is organised, and what the branches tell you

The repository is a C# solution, with wolverine.slnx at the root alongside a slim variant and an F# variant, so the project is exercised from more than one language surface. Documentation lives in /docs and is built with VitePress, with code samples pulled from real source files by MarkdownSnippets. That detail matters more than it sounds: the samples in the documentation are generated from the codebase, so a snippet that drifts from the source is a build problem rather than a silent documentation lie. The branch layout is the clearest signal about maturity. main is described as active development for Wolverine 6.0, published as WolverineFx 6.0.0-alpha.* pre-release packages, with breaking changes and dependency bumps to in-development JasperFx 2.0-alpha packages expected. The 5.0 branch was cut from the V5.39.0 tag and receives bug fixes only, no new features and no breaking changes. There is also an archive/cloudevents-attempt-2025 branch, preserved and abandoned, an incomplete CloudEvents for SQS and SNS feature that never merged. That branch is worth noting because it is the kind of thing a README usually hides. Here it is labelled plainly. The last push to the repository was on 2026-08-28, and the most recent releases listed are 6.30.3, 6.30.2 and 6.30.1, all in late August 2026.

Installing Wolverine and getting a first handler running

The README does not contain package installation instructions. It points at the documentation website at wolverinefx.net, and the repository ships the documentation source under /docs. That is where the getting started material lives, so treat the site as the install path rather than the README. The one concrete build instruction the README does give concerns the repository itself: open wolverine.slnx at the root. To run the integration tests you need Docker installed locally, and the README gives this command to start the matching testing services:

docker compose up -d

After that command, the services declared in docker-compose.yml come up, which includes Postgres on host port 5433, Mosquitto on 1883, and a Google Cloud Pub/Sub emulator on 8085. The Postgres service is started with max_connections=500 rather than the default 100, and the comment in the compose file explains why: the Marten CI job runs the whole MartenTests project in a single process, so connection pools from every test class accumulate, and the default of 100 overflowed with "53300: sorry, too many clients already". If you are running the suite locally on a machine where 500 connections is not realistic, that is the first thing you will have to change. There is no local emulator for Azure Service Bus. The README is explicit that those tests require an actual cloud setup, and the compose file carries a separate emulator network for that case. Building the repository itself is scripted with Nuke in the /build folder: use build on Windows, or ./build.sh on macOS or Linux. The documentation site has its own workflow, and it needs a recent Node.js version. Two npm scripts matter, and package.json confirms both:

npm install
npm run docs

npm run docs runs mdsnippets first and then starts VitePress in dev mode on port 5050 with the browser opening automatically. If you only want to regenerate the code samples from source, npm run mdsnippets does that on its own.

Where the README leaves you on your own

The README is a contributor document, not a user document. It explains branches, naming conventions and how to build the docs, and it defers everything else to wolverinefx.net. For someone evaluating Wolverine, that means the repository alone will not tell you which transports are supported, what the handler discovery rules are, or how the mediator differs from the message bus at the API level. You have to go to the documentation site, and for 6.0 you have to go to the migration guide as well, because the README says the 6.0 work includes changed defaults, removed APIs and moved namespaces. That is a real cost: the at-a-glance table is linked from the README, but the README itself does not summarise it, so an upgrade decision cannot be made from the repository page. The contributor guide also encodes a naming convention that will surprise people: public and internal members are Pascal cased, private and protected members are Camel cased, and private fields use an underscore prefix. The README attributes this to the maintainer with some humour, but it is a real constraint on pull requests. The Azure Service Bus test situation is the other honest limitation. Microsoft does not ship a local Docker emulator for it, so those tests cannot run in a hermetic CI container the way the Postgres, Mosquitto and Pub/Sub tests can.

Wolverine compared with MediatR

The natural comparison for the mediator half is MediatR, which is an in-process mediator and stops there. Wolverine's README describes it as a mediator and a message bus, so the difference is scope rather than style: with MediatR you add a separate transport library and wire the two together yourself, while Wolverine's premise is that the same handler model serves both in-process dispatch and cross-process messaging. That is the reason the Marten pairing is called out in the history section, since Marten supplies the persistence side of the same stack. The trade-off is that you are adopting a larger framework with its own conventions and its own release cadence, and the 6.0 alpha line is currently carrying breaking changes. A team that only ever needs in-process request dispatch gets a smaller surface and a calmer upgrade path from MediatR. A team that already knows it will need messaging eventually is the case Wolverine is built for.

Licence, support and what an upgrade costs

Wolverine is MIT licensed, which permits commercial use and modification under the terms of that licence. The README adds that JasperFx Software offers paid support and consulting contracts, and links to jasperfx.net, so there is a commercial option alongside the open source project. Nothing in the repository suggests the licence changes for the paid tier, but the README does not spell out the boundary either, so if support terms matter to your organisation, read them at the source rather than inferring from the README. On upgrade cost, the branch structure is the whole story. The 5.0 branch takes bug fixes only, so staying on 5.x is low effort but capped. Moving to 6.0 means reading the migration guide for changed defaults, removed APIs and moved namespaces, and accepting dependency bumps to in-development JasperFx 2.0-alpha packages. Both paths are documented, which is more than many projects manage, but the 6.0 path is explicitly labelled as expecting breaking changes.

Editorial conclusion

Adopt Wolverine if you are building .NET server side services and want handler dispatch and messaging under one programming model, and if you can read the documentation site and the migration guide rather than relying on the README. Do not adopt it if you need a stable API surface today: main is publishing WolverineFx 6.0.0-alpha.* pre-release packages with breaking changes expected, so the 5.0 branch is the conservative choice. Before committing, verify the package version you actually pull, whether your transport has a local Docker emulator in docker-compose.yml, and which of the 6.0 changes in the migration guide touch the APIs you already use.

Frequently asked questions

Official sources

1. Official documentation
2. Official README
3. Project repository
4. Release notes