Strategies for upgrading BullMQ to newer versions in production
BullMQ’s team regularly releases new versions with bug fixes, new features, and occasionally breaking changes. This guide helps you upgrade safely while maintaining service continuity in production.
Always consult the Changelog before upgrading to understand the extent of changes and any special considerations.
Ensure all Queue and Worker instances run the new version before using new features.
3
Verify all instances are updated
Check that all services are running the new version.
4
Deploy code using new features
Only after confirming all instances are updated, deploy code that depends on the new functionality.
If you deploy code using new features before all instances are updated, older Workers might fail when encountering jobs that use features they don’t understand.
Version Pattern: Major version increase (e.g., 3.x.x → 4.0.0)Strategy: Depends on the type of breaking changeBreaking changes fall into two categories:
// Option 1: Different queue nameconst oldQueue = new Queue('myqueue');const newQueue = new Queue('myqueue-v2');// Option 2: Different prefixconst newQueue = new Queue('myqueue', { prefix: 'bull-v2',});// Option 3: Different Redis hostconst newQueue = new Queue('myqueue', { connection: { host: 'new-redis.example.com', port: 6379, },});
2
Run both versions in parallel
Maintain two versions of your service:
Old service: Older BullMQ version with old queues
New service: Latest BullMQ version with new queues
// Old serviceimport { Worker as OldWorker } from 'bullmq-v3';const oldWorker = new OldWorker('myqueue', processor, { connection: oldRedisConfig,});// New serviceimport { Worker } from 'bullmq';const newWorker = new Worker('myqueue-v2', processor, { connection: newRedisConfig,});
3
Direct new jobs to new queues
Update your producers to add jobs to the new queues: