Bull is a battle-tested, Redis-backed job manager for Node.js, designed to handle background tasks, deferred processes, and distributed workloads with a strong emphasis on stability and atomicity. The current stable version is 4.16.5. As of recent updates, the project is in 'maintenance mode,' meaning it primarily receives bug fixes and security updates, with new feature development largely ceasing. Its release cadence is irregular, driven by necessary patches for critical issues like CVEs (e.g., cron-parser) and runtime errors (e.g., msgpackr buffer issues). Bull distinguishes itself through its robust, polling-free design for minimal CPU usage and reliable 'at least once' job processing semantics. For new projects and active feature development, users are strongly encouraged to consider BullMQ, which is a modern rewrite in TypeScript and the actively maintained successor.
npm install bullVerified import paths — ran on the pinned version, not inferred.
This quickstart demonstrates how to create a Bull queue, add a job with options like retries and delays, and set up a worker to process jobs asynchronously. It also includes basic event listeners for job completion and failure, and a graceful shutdown mechanism.
For new applications, use BullMQ. For existing Bull applications, plan a migration to BullMQ for future-proofing and access to new features.
Ensure you are passing an instantiated `ioredis` client to the `connection` option of the `Queue` constructor: `new Queue('my-queue', { connection: new IORedis() });`.Optimize job processing logic to avoid blocking the Node.js event loop for extended periods. Consider using sandboxed processors (`queue.process('./path/to/processor.js')`) for CPU-intensive tasks. Monitor worker CPU usage and Redis connection health. Increase `lockDuration` if necessary, but be aware of the tradeoff.Upgrade to Bull `v4.16.5` or a newer version to receive the fix for the `cron-parser` CVE.
Upgrade to Bull `v4.16.4` or a newer version to get the fix by bumping `msgpackr` to version 1.1.2 or higher.
Verify that your Redis server is running and accessible from the application's host and port (default is `localhost:6379`). Check firewall rules. Ensure the `redis` or `connection` options in the Bull `Queue` constructor correctly point to your Redis instance.
Optimize job processing code to be less CPU-intensive, use sandboxed processors, or increase `lockDuration`. Check network stability to Redis. Ensure Redis `maxmemory-policy` is set to `noeviction` to prevent Redis from prematurely deleting keys.
Validate all environment variables and dynamic parameters before passing them to Bull constructors or methods. Ensure they are always defined and of the correct `string` or `number` type, using default values or throwing explicit errors if they are missing.