BullMQ
Robust, full-featured Node.js job queue built on Redis. Evolution of Bull with rewritten TypeScript, improved Redis Streams support, job flows (parent-child dependencies), rate limiting, sandboxed processors, and priority queues. The most production-grade Redis-backed job queue for Node.js agent task processing.
Score Breakdown
⚙ Agent Friendliness
🔒 Security
Redis URL contains credentials — use environment variables. Job data stored in Redis — avoid storing secrets in job data. Worker processes execute arbitrary code — sandbox untrusted job data.
⚡ Reliability
Best When
You're building a Node.js agent service that needs reliable background job processing with priority queues, retries, rate limiting, and job dependency flows.
Avoid When
You don't have Redis or need multi-language support — use Celery for Python-based agents or Faktory for cross-language job queuing.
Use Cases
- • Queue and process background agent tasks (LLM API calls, file processing, email sending) with automatic retries and dead letter queues
- • Implement priority-based agent task queues where critical jobs are processed before low-priority ones
- • Create job flows (parent/child jobs) for complex multi-step agent workflows with dependency ordering
- • Rate-limit agent API calls using BullMQ's built-in rate limiter to stay within LLM API quotas
- • Schedule recurring agent tasks with cron expressions via BullMQ's repeat job functionality
Not For
- • Event streaming at Kafka scale — BullMQ is optimized for job queuing, not streaming millions of events per second
- • Environments without Redis — BullMQ requires Redis as its sole storage backend
- • Multi-language agent systems — BullMQ is Node.js only; use Celery for Python or Faktory for multi-language support
Interface
Authentication
Redis URL includes auth. No application-level auth in BullMQ itself. Bull Board UI dashboard available separately.
Pricing
MIT license core. BullMQ Pro adds group queues, observability, and priority advanced features.
Agent Metadata
Known Gotchas
- ⚠ Worker processes that crash without proper signal handling leave jobs in 'active' state — implement SIGTERM/SIGINT handlers to gracefully close workers; stalled jobs are reclaimed after lock expiry
- ⚠ Job concurrency must be balanced with worker memory — high concurrency (100+ concurrent jobs) with memory-intensive agent tasks causes OOM; tune concurrency per worker resources
- ⚠ BullMQ sandboxed processors run in child processes — module-level state (DB connections, caches) is not shared with parent process; initialize connections inside processor
- ⚠ Job flow (parent/child) completion order is guaranteed only within the flow — child jobs can complete in any order; parent waits for all children before completing
- ⚠ Redis key expiration TTL for completed jobs must be set (defaultJobOptions.removeOnComplete) — completed jobs accumulate in Redis indefinitely without cleanup causing memory pressure
- ⚠ BullMQ requires ioredis (not redis) client — using the wrong Redis client causes cryptic errors; always use ioredis with BullMQ
Alternatives
Full Evaluation Report
Detailed scoring breakdown, competitive positioning, security analysis, and improvement recommendations for BullMQ.
Scores are editorial opinions as of 2026-03-06.