@nestjs/bullmq

@nestjs/bullmq wires the BullMQ Redis-backed job queue library into NestJS’s dependency injection and module system, letting queues, producers, and processors be declared with the same @Module/@Injectable/decorator patterns used elsewhere in a Nest application. It registers queues via BullModule.registerQueue() (or forRootAsync for dynamic configuration), and exposes @Processor, @Process, and event decorators so job handlers and lifecycle listeners are just NestJS providers.

The package lives in the nestjs/bull monorepo alongside the older @nestjs/bull module (for the legacy Bull library) and a shared bull-shared package. @nestjs/bullmq is the actively recommended integration going forward, since it targets BullMQ — the actively maintained successor to Bull with Redis Streams-based reliability improvements — while @nestjs/bull remains for existing Bull-based codebases.

What You Get

• BullModule.registerQueue() / forRootAsync() for declaring and configuring queues through NestJS’s module system, including async config via ConfigService
• @Processor and @Process/@OnWorkerEvent decorators for defining job handlers and lifecycle listeners as ordinary injectable providers
• Automatic queue and worker lifecycle management tied to the Nest application’s own bootstrap and shutdown hooks
• Support for named jobs, job options (delay, priority, repeat, backoff), and flow producers exposed through BullMQ’s API
• Testing utilities for mocking queues in unit tests without a live Redis connection
• TypeScript types covering job payloads, processor return values, and queue events

Common Use Cases

• Offloading slow work (email sending, report generation, image processing) from NestJS HTTP request handlers into background jobs
• Building scheduled or recurring tasks using BullMQ’s repeatable jobs from within a Nest service
• Coordinating multi-step workflows with BullMQ flow producers, orchestrated through Nest’s DI-managed processors
• Rate-limiting and throttling outbound API calls by routing them through a Nest-managed BullMQ queue with concurrency limits
• Migrating an existing Bull-based Nest app to BullMQ using the parallel @nestjs/bullmq module while keeping familiar Nest module patterns

Under The Hood

Architecture - The bullmq package (packages/bullmq/lib) centers on bull.module.ts, bull.providers.ts, and bull.registrar.ts, which translate BullModule.registerQueue() calls into NestJS dynamic-module providers that construct and cache BullMQ Queue/Worker instances per queue name. bull.explorer.ts scans the application’s provider metadata at bootstrap for @Processor/@Process-decorated classes and methods and wires them to the corresponding BullMQ worker, so job processing hooks into Nest’s own module-instantiation and lifecycle-event system rather than requiring separate startup code.

Tech Stack - Written in TypeScript, published from a Lerna-managed monorepo (nestjs/bull) that also contains the legacy @nestjs/bull (for Bull) and a bull-shared package with logic reused by both. @nestjs/bullmq’s only queue-engine dependency is the peer package bullmq itself, plus @nestjs/core/@nestjs/common as peer dependencies for the DI integration; it does not bundle Redis client code, relying on BullMQ’s own Redis (ioredis) connection handling.

Code Quality - The package has unit specs alongside an e2e/ directory with a dedicated vitest.config.e2e.mts, indicating processors and queue registration are verified against a real BullMQ/Redis instance rather than mocks alone. Renovate is configured at the monorepo root to keep BullMQ and NestJS core dependency versions current, and oxlint.json enforces consistent linting across all three packages in the repo.

API Design - The module deliberately mirrors NestJS’s existing conventions: registering a queue looks like registering any other dynamic module, and defining a processor looks like defining a controller or service with decorated methods. This keeps the learning curve low for teams already using NestJS, though it does mean the module’s ergonomics are bounded by BullMQ’s own API surface for job options, retries, and flows — @nestjs/bullmq adds DI wiring on top rather than a new abstraction.