For a compatible Redis-backed installation, replace the operational interface in stages. Keep queue identities, producers, workers, and job data unchanged.
- 01Record the baseline
Capture connections, prefixes, counts, permissions, and required workflows.
- 02Run both views
Connect the replacement and validate it against staging before production.
- 03Retire the old route
Remove only dashboard wiring after parity checks. Keep the producer and worker code.
1. Identify the problem you are solving
Write down the reason for the change: multiple environments, team access, notification workflows, agent access, or an interface that is easier for your operators. Check your installed Bull Board version and current documentation first. A configuration change or upgrade may address the problem without replacing the tool.
Create acceptance criteria that an engineer can demonstrate. For example: an operator can find a failed job in the correct environment, inspect its error, and retry it with the intended access controls. Avoid vague criteria such as “better monitoring” that make a migration impossible to evaluate.
2. Inventory the configuration you must preserve
Record every queue’s Redis endpoint, logical database, prefix, queue name, and BullMQ version. Include TLS settings and network access. Check whether the same queue name appears in more than one environment. Confirm the replacement supports the features you use, including flows and recurring schedulers. Durabull shows job schedulers and waiting-children counts but does not draw flow graphs; if your operators rely on Bull Board’s flow view, treat that as a gap to evaluate.
Inspect how your application creates queue instances. An instance passed to Bull Board may also be exported to producers or used by scheduler initialization. Removing that instance simply because the dashboard no longer needs it can break application behavior. Remove dashboard-only wiring, not shared queue construction.
Keep this inventory free of credentials in tickets and screenshots. Store secrets through your deployment’s normal secret mechanism and give each connection a clear environment label.
3. Connect the replacement in staging
For Durabull, configure the Redis connection and matching BullMQ prefix. Environment-managed connections can declare the same information in deployment variables. The example shows the shape of that configuration with a placeholder hostname; inject credentials securely if the instance requires them.
A successful Redis connection is only the first check. Confirm the expected queues are discovered, open a known job ID, and inspect a scheduled job and a parent job waiting on children if your application uses them. When discovery is empty, check database, prefix, and permissions before changing any queue state.
DURABULL_ENV_CONNECTIONS=true
DURABULL_REDIS_URL_STAGING=rediss://redis.example.internal:6379/0
DURABULL_REDIS_URL_STAGING_ENVIRONMENT=staging
DURABULL_REDIS_URL_STAGING_PREFIX=bull
DURABULL_REDIS_URL_DEFAULT=STAGING4. Compare evidence while both interfaces are available
Keep Bull Board available during validation. Compare a known set of job IDs and recent states, rather than expecting two live count snapshots taken seconds apart to match exactly. Active workers can change those counts between requests.
Test historical charts separately from current job inspection. If worker metrics were never enabled, a new dashboard cannot reconstruct missing BullMQ minute buckets. Check retention and job-log coverage, and document any capability that relies on a background collector or application instrumentation.
Test the operator account that will actually use the tool, not only the administrator who installed it. Verify that production and staging are distinguishable, sensitive data is appropriately accessible, and unavailable evidence is shown clearly.
5. Rehearse recovery, then remove old wiring
Create a controlled staging failure with a harmless side effect. Inspect the error, fix its cause, retry once, and verify completion. If production jobs perform externally visible actions, review their idempotency contract before enabling routine recovery for more operators.
After the acceptance checks pass, remove the old dashboard route and imports. Remove packages only if no other code uses them. Preserve shared queues, producers, workers, and scheduler setup. Update runbooks, bookmarks, reverse-proxy rules, and any alert links that point to the old interface.
Prepare rollback as a UI deployment change: restore the old route and its access controls if necessary. You should not need a job-data migration for this dashboard switch. Keep a record of the verified backend and version so a later runtime upgrade does not silently invalidate compatibility assumptions.
Common questions
Will replacing Bull Board delete or move my jobs?
Connecting a compatible replacement and removing only the dashboard route does not migrate job data. Avoid deleting queue instances used elsewhere, changing queue names or prefixes, or invoking cleanup operations during the switch.
Can I run Bull Board and Durabull together during migration?
You can validate both against the same supported Redis-backed queues. Expect live counts to change between reads, account for additional monitoring traffic, and coordinate any write operations.
Do workers need a new SDK when moving to Durabull?
No Durabull worker SDK is required for queue inspection. Existing BullMQ metrics and job logging configuration determine what historical charts and logs are available.
Sources & review
Written by Durabull. Reviewed against the references below and Durabull’s implementation. Pricing examples are documented models, not measured benchmarks or vendor quotes.
Suggest a correction if a feature, price, or documented behavior has changed.
Compare the options
- Durabull vsBull BoardMIT dashboard with embedded adapters and a standalone Redis-discovery CLI.
- Durabull vsWorkbenchMIT BullMQ dashboard with Redis discovery, alerts, a desktop app, and local MCP. Discovery limits are configurable.
- Durabull vsTaskforce.shHosted dashboard by the BullMQ authors. Auto-discovers queues. Priced per Redis connection. Includes MCP.
- Durabull vsArenaExpress GUI for Bee, Bull, and BullMQ. You name every queue in config.