Rebus: a lean .NET service bus for smart endpoints and dumb pipes

What Rebus solves, and for whom

Rebus is a service bus implementation for .NET, described in its README as "lean" and as a message bus "without smarts", a phrase the README attributes to ThoughtWorks in 2010. The problem it addresses is the one that appears when a .NET application is split into services and direct method calls no longer work: one service needs to hand work to another without waiting for it, and neither side should need to know where the other lives. Rebus gives you a bus object that sends messages and a set of handlers that receive them.

The intended audience is .NET developers who follow the "smart endpoints, dumb pipes" principle. In that style the bus moves bytes and the services hold the logic. If you expect the middleware to transform, enrich or orchestrate messages, Rebus is pointedly not that. The README lists its own goals: a simple configuration story, a few well-selected options, no doodleware, and as few dependencies as possible. The dependency list is short enough to state exactly: JSON.NET, and nothing else in the core package.

The RebusBus object and the configuration API

Everything in the core library revolves around the RebusBus class. The README shows two ways in. The manual route constructs a bus directly and starts it with a worker count:

var bus = new RebusBus(...);
bus.Start(1); //< 1 worker thread

// use the bus for the duration of the application lifetime

// remember to dispose the bus when your application exits
bus.Dispose();

The ellipsis is the important part. The dependencies vary depending on how you send and receive messages, so the manual constructor is not a complete recipe on its own. Most readers will take the second route, the configuration API, which is fluent and reads top to bottom.

You start by choosing a container adapter. The built-in one is `BuiltinHandlerActivator`; for an external container you write or reuse an adapter, shown in the README as `new AdapterForMyFavoriteIocContainer(myFavoriteIocContainer)`. You then configure logging, a transport, and routing, and call `Start()`. The README's example uses `t.UseMsmq("myInputQueue")` for the transport and `r.TypeBased().MapAssemblyOf<SomeMessageType>("anotherInputQueue")` for routing. After that the resulting `IBus` is registered as a singleton in the container and the container is used to look up message handlers. That is the whole wiring story, and its brevity is the design intent rather than an accident.

Routing by type, and the namespace variant

The routing configuration is type-based. `MapAssemblyOf<SomeMessageType>` inspects the assembly that contains the given message type and maps those types to a destination queue. The README gives a second variant for shared assemblies: `MapAssemblyNamespaceOf<SomeMessageType>` maps only the types under a specific namespace. That distinction matters when one assembly is used by several services and you do not want every type in it routed to the same queue.

What the README does not show is how routing behaves when a type is matched by more than one rule, or what happens at send time when no mapping exists. The README is silent on both, and the configuration section it points to lives on the official documentation wiki rather than in the repository. Treat routing as a thing to verify against your own assembly layout before you rely on it.

Installing Rebus and sending a first message

The core package is published on NuGet as `Rebus`, and the README links the stable and prerelease badges to nuget.org. The README does not give a command-line install step, so the package page is the place to start.

You will also need a transport. The README's own configuration example uses MSMQ, and the repository points to "the many integration libraries" under the rebus-org GitHub organisation for other transports. Pick the one that matches your broker before writing configuration code.

The configuration API needs a container adapter, a logging adapter, a transport and a routing rule. The README's example, condensed to the parts that matter, looks like this:

Configure.With(someContainerAdapter)
    .Logging(l => l.Serilog())
    .Transport(t => t.UseMsmq("myInputQueue"))
    .Routing(r => r.TypeBased().MapAssemblyOf<SomeMessageType>("anotherInputQueue"))
    .Start();

After `Start()` returns, `IBus` is available from the container as a singleton. Inject it into whatever service sends messages, and register handlers in the container so Rebus can look them up. When the application exits, dispose the container, which disposes the bus. The README notes that the bus must live for the duration of the application lifetime, so creating one per request is not the intended pattern.

Where Rebus stops and you have to start

The README is honest about the scope of the core repository: it contains Rebus "core", and integrations live in separate projects. That means the transport you need is probably not in the package you just installed. If your broker has no integration library, you are writing one.

The second limitation is the container adapter. The built-in `BuiltinHandlerActivator` exists, but for anything else you supply an adapter for your IoC container. The README's `AdapterForMyFavoriteIocContainer` is a placeholder, not a type you can reference. If your container is unusual, that is work you own.

The third is operational. The README mentions a commercial add-on covering "support, tooling, etc." and links to Rebus Pro on rebus.fm. Nothing in the core README describes a management UI, a retry dashboard or message replay. If your team expects the bus to ship with those, Rebus core is the wrong starting point, and the honest comparison is against platforms where operations are part of the product rather than an add-on.

Rebus compared with a full messaging platform

The closest alternative in spirit is a full service bus or messaging platform, where the middleware itself owns routing rules, transformation and monitoring. Rebus pushes all of that to the endpoints. The practical difference shows up at configuration time: with Rebus you write the container adapter, the transport choice and the type mappings in application code, and the bus does what those lines say. With a platform, you configure those things in the broker and the application code stays thinner.

There is a second axis. Rebus targets .NET Standard 2.0, which the README spells out as .NET Framework 4.6.1, .NET Core 2, and .NET 5 and onwards. That is a broad reach for a .NET library, but it is still a .NET library. If your services are polyglot, a broker-level platform that speaks to every runtime is the more natural fit, and Rebus will not help the non-.NET side.

Maintenance, licence and upgrade cost

The repository is not archived, and the last push was on 2026-09-17. The solution file in the repository root is named `Rebus8.sln`, which suggests the current line is version 8, though the README does not state a version number. There is a CHANGELOG.md at the top level, so upgrade notes have a home; whether every release is documented there is not something the README confirms.

The README states that Rebus is licensed under The MIT License (MIT), with the licence text in LICENSE.md. It also says the licence "grants you the right to use Rebus in any way you see fit" and that the intent is to make it easy to use Rebus and its integration libraries, with a contact address for cases where that is not true. Note that the repository metadata reports the licence as NOASSERTION, which does not match the MIT statement in the README; if licence terms matter to your organisation, read LICENSE.md itself rather than either label. The README also states that Rebus is free and will stay that way forever, which is a promise about the core library, not about the commercial add-on it mentions separately.

Editorial conclusion

Adopt Rebus if you are building .NET services that need asynchronous, type-routed messaging and you are willing to pick a transport and a container adapter yourself. Do not adopt it if you need the bus to own routing policy, retries or operational tooling out of the box, since the README points to separate integration libraries and a commercial add-on for that. Before committing, verify which transport package matches your broker, whether the container you already use has an adapter, and how the type-based routing maps your assemblies.

Frequently asked questions

Official sources

1. Issues
2. Project website
3. README
4. rebus-org/Rebus on GitHub