Announcing BullMQ for .NET

BullMQ is now available for .NET. Version 1.0.0 of the official C# library is published on NuGet as BullMQ:

dotnet add package BullMQ

Queues and workers in C#

The API follows the conventions of .NET: methods are asynchronous, queues and workers are IAsyncDisposable, and events are regular C# events.

using BullMQ;

await using var queue = new Queue("emails", new QueueOptions
{
    Connection = ConnectionOptions.FromString("localhost:6379"),
});

await queue.AddAsync("welcome", new { to = "user@example.com" });

await using var worker = new Worker("emails", async (job, ct) =>
{
    Console.WriteLine($"Processing {job.Name} #{job.Id}");
    return "sent";
}, new WorkerOptions
{
    Connection = ConnectionOptions.FromString("localhost:6379"),
    Concurrency = 5,
});

worker.Completed += (job, result) =>
    Console.WriteLine($"Job {job.Id} completed with '{result}'");

If your application already has a StackExchange.Redis connection, you can pass the IConnectionMultiplexer to BullMQ and reuse it across queues and workers.

Redis or PostgreSQL

The Queue, Worker and Job classes run on Redis 6.2 or newer, or a compatible server such as Valkey or Dragonfly. The same classes can also run on PostgreSQL 13 or newer. Set Postgres on the options, and the tables BullMQ needs are created automatically the first time they are used:

using BullMQ;
using BullMQ.Postgres;

var pg = new PostgresOptions
{
    ConnectionString = "Host=localhost;Database=bullmq;Username=postgres;Password=postgres",
};

await using var queue = new Queue("emails", new QueueOptions { Postgres = pg });
await queue.AddAsync("welcome", new { to = "user@example.com" });

await using var worker = new Worker("emails", async (job, ct) => "sent",
    new WorkerOptions { Postgres = pg, Concurrency = 5 });

The library requires .NET 8.0 or newer.

The same scripts as every other BullMQ library

BullMQ for .NET is a thin layer of C# on top of the same Lua and SQL scripts that the Node.js, Python, PHP, Elixir and Rust libraries run. Those scripts decide what happens to a job when it is claimed, completed, retried or moved, and they are the part of BullMQ that has been tested in production the longest.

Sharing them also makes the queues compatible. A queue filled by a Node.js service can be processed by a .NET worker, and the other way around, so you can bring .NET into a system that already uses BullMQ without migrating anything.

What comes next

This release includes Queue, Worker and Job on both backends. FlowProducer, QueueEvents and JobScheduler are being added next, to bring the library to full parity with the others.

The guide is in the BullMQ documentation, and the source lives next to the other implementations in the BullMQ repository. If you run into anything, please open an issue.

Update: FlowProducer, QueueEvents and JobScheduler have since been added. See BullMQ for .NET for what the library supports today.