Wolverine is a Next Generation .NET Mediator and Message Bus. Check out the documentation website at https://wolverinefx.net/.

While Wolverine is open source, JasperFx Software offers paid support and consulting contracts for Wolverine.

Become a Sponsor on GitHub

To work with the code, just open the wolverine.slnx file in the root of the repository and go. There's also wolverine_slim.slnx, a lighter variant that omits several extension projects, and wolverine_fsharp.slnx. CI builds the full wolverine.slnx, so build that one before pushing:

dotnet build wolverine.slnx -c Release -f net9.0

If you want to run integration tests, you'll want Docker installed locally and to start the matching testing services with:

docker compose up -d

That covers Azure Service Bus too — it runs against the Azure Service Bus emulator, so no cloud subscription is needed. See the Azure Service Bus tests README for the ports it uses and why there are two emulator instances.

This repository follows a major-line branching strategy:

• main — Active development for the Wolverine 6.x line, which is generally available and shipping regular releases. Day-to-day work, new features, the cold-start / runtime-perf pass and the AOT pillar all land here. See the migration guide for the at-a-glance table of changed defaults / removed APIs / moved namespaces from 5.x.
• 5.0 — Maintenance branch for the Wolverine 5.x line, branched from the V5.39.0 tag. Receives bug fixes only — no new features and no breaking changes. Patch releases off the 5.x line ship from this branch.
• archive/cloudevents-attempt-2025 — Preserved, abandoned. An incomplete CloudEvents-for-SQS-and-SNS feature branch from August 2025 that never merged. Kept for historical reference only.

Older release-specific branches (e.g., 4.0, release/5.30, 5.36) exist for in-flight or completed work on prior versions and are not active development surfaces. New contributions should target main. Backport candidates for the 5.x line can be opened against 5.0 after the corresponding PR has merged to main.

For contributors, there's a light naming style Jeremy refuses to let go of that he's used for gulp 20+ years. The thing to internalize is that casing follows accessibility, not member kind:

1. All public or internal members should be Pascal cased
2. All private or protected members should be Camel cased — including private static helper methods
3. Use _ as a prefix for private fields
4. Constants are Pascal cased whatever their accessibility

So a single class routinely mixes both, and that's intentional:

public class SqlServerQueue
{
    private readonly SqlServerTransport _parent;

    public Task SendAsync(Envelope envelope) { ... }   // public  -> Pascal

    private void buildSenderIfMissing() { ... }        // private -> camel
}

If you're coming from a codebase that Pascal cases every method regardless, rule 2 is the one that will catch you out. These rules are encoded in .editorconfig, so your IDE will flag new violations as you type. They surface in the IDE and in dotnet format, but never fail the build — there's a fair amount of pre-existing drift, and renaming a protected member is a breaking change for anyone subclassing it, so please don't mass-fix what's already there.

Please leave CHANGELOG.md alone in a pull request. Every concurrent branch appends to the same "Unreleased" section, so every one of them conflicts with every other on merge. The PR description and the commit message are where a change explains itself, and both are attached to the work forever. Release notes are a release-time job.

The build is scripted out with Nuke in the /build folder. To run the build file locally, use build with Windows or ./build.sh on OSX or Linux.

All the documentation content is in the /docs folder. The documentation is built and published with Vitepress and uses Markdown Snippets for code samples. To run the documentation locally, you'll need a recent version of Node.js installed. To start the documentation website, first run:

npm install

Then start the actual website with:

npm run docs

To update the code sample snippets, use:

npm run mdsnippets

This is a little sad, but Wolverine started as a project named "Jasper" way, way back in 2015 as an intended reboot of an even older project named FubuMVC / FubuTransportation that was a combination web api framework and asynchronous message bus. What is now Wolverine was meant to build upon what we thought was the positive aspects of fubu's programming model but do so with a much more efficient runtime. Wolverine was largely rebooted, revamped, and renamed in 2022 with the intention of being combined with Marten into the "critter stack" for highly productive and highly performant server side development in .NET.