BullMQ is excellent—until you’re debugging stuck, delayed, or failing jobs across multiple workers and environments. At that point, you’re usually jumping between logs, Redis tooling, and ad-hoc scripts.
That’s why I built bullstudio: an open-source BullMQ dashboard that you run like Prisma Studio—one command, browser opens, no app integration required.
Repo: https://github.com/emirce/bullstudio
Quick start
npx bullstudio -r <redis_url>
Defaults to http://localhost:4000.
Common options:
npx bullstudio # redis://localhost:6379
npx bullstudio -p 5000 # custom port
npx bullstudio --no-open # don't auto-open browser
You can also use env vars:
export REDIS_URL=redis://localhost:6379
export PORT=4000
bullstudio
What you get
- Overview dashboard: queue health + throughput/failure trends
- Jobs browser: filter/search, inspect payload/attempts/stack traces, retry failed jobs
- Flows visualization: interactive parent/child graphs with live state updates
If you’ve ever wondered “why didn’t the parent job run?” or “what exactly failed on attempt #3?”, the flows + job detail views are the whole point.
How it fits with existing tools
There are established dashboards like bull-board and Arena. bullstudio’s focus is:
- BullMQ-first UX
- “just run it” workflow (
npx bullstudio) - flows as a first-class view
Notes for production Redis
bullstudio connects via a Redis URL. If you point it at production:
- keep it internal (VPN/private network/reverse proxy)
- be mindful of sensitive payloads
- prefer env vars over pasting credentials into shell history
Feedback welcome
I’d love input from teams running BullMQ in production:
- must-have actions/views (stalled detection, worker liveness, read-only mode, masking/truncation defaults, etc.)
- edge cases with large payloads or many queues
Top comments (0)