// the find
JasperFx/wolverine
Supercharged .NET server side development!
Wolverine is a .NET message bus and mediator that combines in-process messaging (like MediatR) with durable outbox/inbox patterns and external broker support. It's aimed at teams building event-driven or CQRS-style .NET applications, especially those already using Marten or EF Core. It sits somewhere between NServiceBus and MediatR in scope and complexity.
- Transport coverage is genuinely broad: RabbitMQ, Azure Service Bus, SQS, Kafka, NATS, MQTT, Pulsar, GCP Pub/Sub, Redis, plus SQL-backed transports — most with conventional routing and dead letter queue support out of the box.
- Source-generated handler pipelines via JasperFx's code generation avoid reflection at runtime, which gives it real throughput advantages over reflection-heavy alternatives like MediatR.
- Durable outbox/inbox is first-class and works across multiple persistence backends (Marten, EF Core with SQL Server/PostgreSQL/MySQL/SQLite/Oracle, RavenDB), not bolted on as an afterthought.
- Active maintenance with CI workflows split per transport/persistence backend, meaning integration test coverage is actually run against real infrastructure per component — not just mocked.
- The source-generation magic (Lamar + JasperFx.CodeGeneration) is opaque when things go wrong; debugging why a handler pipeline isn't wiring correctly means digging into generated C# files that most developers won't expect to have to read.
- Heavy JasperFx ecosystem coupling — you get the most value if you're also using Marten (Polecat), which creates a real lock-in risk. Using it purely as a mediator replacement or with non-Marten stacks means you leave most of the interesting features on the table.
- Azure Service Bus integration requires actual cloud infrastructure for integration tests (acknowledged in the README), which is a legitimate gap that will slow CI/CD setup for teams standardizing on that broker.
- The project has a long history of renames and pivots (FubuMVC → Jasper → Wolverine), and some documentation still feels inconsistent between old and new patterns — the migration guide exists, but conceptual terminology shifts between docs pages.