Changelog

Flow maps you can read at a glance.

Fixed

• Arrowheads. Arrows on flow maps now show which way the work goes. They were missing in 0.7.0.
• FlowProducer flows read left to right. The parent queue sits on the left and fans out to the child queues it waits for, on flow maps and on "All queues".

Flow maps: draw how work moves through your queues, or let your AI draw it.

Added

• Flow maps (Pro). Name a process and draw the queues it goes through, for example checkout → payment-capture → email-send and pick-pack, with live counts on every queue. A map can cross connections, from one Redis to another or to Postgres, and each connection gets its own colour. Maps can nest like folders if you want, and the layout the team arranges is saved for everyone.
• Detected maps. Queues linked by BullMQ's FlowProducer show up as maps on their own, rooted at the parent queue. Copy one to edit it.
• Draw them from your AI client. New MCP tools (create_flow_map, add_flow_edge and more) let Claude or any MCP client read your code and draw the flow, while the page updates live.

Run a whole group, or a whole campaign, now.

Added

• Promote every delayed job of a group, or of a search. "Promote all delayed" on a group and "Promote all matches" on a search in the delayed tab promote every matching job, not only the 500 that fit a selection. The dialog works in bounded batches, shows the running count and can stop between them. On a BullMQ Pro queue the jobs go back into their group and keep its limits.
• Group actions on the queue page. With a group filter on, a toolbar pauses, resumes, promotes or drains that group, including groups BullMQ Pro has not indexed because all their jobs are delayed.

Fixed

• The waiting count of a BullMQ Pro queue counts the jobs waiting in groups. A queue with thousands of grouped jobs used to say "waiting 0".
• The group filter offers groups whose jobs are all delayed.

Thanks to Matheus Carvalho for this release.

BullMQ Pro groups: pause, resume, drain, and actions that keep jobs in their group.

Added

• Pause, resume and drain a BullMQ Pro group from the group page and from MCP (pause_group, resume_group; draining stays a confirmation link). Drain is admin-only.

Fixed

• Job actions no longer take a job out of its BullMQ Pro group. Promote and retry used to put a grouped job in the queue-wide wait list, where it ran with no group concurrency or rate limit, even while its group was paused. With BullMQ Pro's package installed next to Bullpane, every write on a Pro queue runs Pro's own scripts; without it, the writes that would break a group are refused with a clear message. Thanks to Matheus Carvalho for the change and João Victor Chagas for the report.

Upgrading

• On BullMQ Pro queues, install BullMQ Pro's package next to Bullpane first, or promote, retry and drain of grouped jobs are refused. It is commercial, so you install it with your own Taskforce token; the guide is in docs/BULLMQ-PRO.md. Queues without groups and Postgres queues are unaffected.

A BullMQ Pro group's delayed jobs, found.

Fixed

• A BullMQ Pro group's delayed jobs can be found. Pro keeps only waiting jobs under their group, so the group filter showed nothing on the other tabs and a group with only delayed jobs was not listed. The group filter now works on every tab, a bounded scan that never reads other groups' payloads; the group page links to its delayed, failed and completed jobs, and the MCP search_jobs tool takes group_id. Thanks to João Victor Chagas for the report and Matheus Carvalho for the fix.
• Known issue, fixed in 0.6.2: promoting or retrying a grouped job still moves it out of its group. Upgrade to 0.6.2 before promoting a group's jobs.

BullMQ on Postgres.

Added

• BullMQ 6’s Postgres backend. Add a connection of kind Postgres with your database URL and the schema BullMQ created (default bullmq), or run npx bullpane --postgres postgres://user:pass@host:5432/db. Queues, counts, job lists, search inside job data, job detail and logs, schedulers, flow trees, metrics, alerts and every action work as on Redis. Reads are SQL on BullMQ’s own tables; writes go through the official BullMQ API. Bullpane never runs migrations on your database.
• Works where Postgres actually runs: behind PgBouncer and other transaction poolers, over TLS with the URL your provider gives you (?sslmode=require means what it means in psql), and with a read-only role, which can browse everything while actions are refused with a clear message.
• Postgres health card: connections against max_connections, transactions per second, database and table sizes, and a warning when BullMQ’s event table, which BullMQ 6 never trims, passes 1 GiB.

Changed

• The health monitor is now “Server health”: it covers Redis and Postgres connections.

Two new ways to run it: Docker Hub and npx.

Added

• Docker Hub. The image is also published as bullpane/bullpane, same tags and platforms: docker run -d -p 3000:3000 -v bullpane-data:/data bullpane/bullpane.
• npx bullpane. The same dashboard without Docker, for a quick look: npx bullpane --redis redis://localhost:6379. Listens on 127.0.0.1 and keeps its SQLite in ~/.bullpane.

Fixed

• A blank page after upgrading. The page that loads the UI was cached for an hour, so a browser that had the previous version open asked for files the upgrade had removed. It is now always revalidated.
• npx bullpane no longer prints a deprecation warning on first run.

No database to set up: SQLite is built in, MySQL is optional.

Added

• No database to set up. Without DATABASE_URL, Bullpane keeps its own data (connections, settings, and on Pro users, alerts, folders, the audit log and MCP clients) in a SQLite file in /data. docker run -p 3000:3000 -v bullpane-data:/data ghcr.io/madmorett/bullpane is the whole install. Mount a volume on /data, or the data dies with the container.
• MySQL is unchanged and still supported. An install that sets DATABASE_URL=mysql://… keeps using MySQL, with no migration on upgrade. Use MySQL when you run more than one replica, or on ECS Fargate. Do not put the SQLite file on NFS/EFS.

Changed

• With DATABASE_URL unset, the default used to be a MySQL on localhost; it is now SQLite. If you relied on that default, set DATABASE_URL to keep your MySQL data. The boot banner says which database is in use.
• The repository’s docker-compose.yml starts MySQL only with COMPOSE_PROFILES=mysql and DATABASE_URL=mysql://bullpane:bullpane@mysql:3306/bullpane in .env. If you ran it with its bundled MySQL, add those two lines before updating: the volume is the same, so your data is where you left it.

Fixed

• A database blip during an alerts tick no longer crashes the server (Pro). The tick now fails, logs, and the next one runs.

Bullpane is now an MCP server: your queues, inside your AI.

Added

• MCP server (Pro). Paste <PUBLIC_URL>/mcp into Claude (claude.ai, Claude Desktop, Claude Code) or any MCP client that supports OAuth, sign in with your Bullpane login or SSO, and pick read or read & write. The client acts as you, through the same API as the dashboard: access is the lowest of the admin’s ceiling (Settings → MCP, off by default), what you approved and your role, re-checked on every call, so a viewer never writes. Writes are in the audit log with via: mcp. Drain, clean and obliterate are never run from MCP: the client gets a link that opens the confirmation dialog. Cloud-hosted clients need PUBLIC_URL to be public HTTPS.

Fixed

• Promoting a job scheduler’s delayed job no longer skips the next run. Promoting one now asks: run a copy now and keep the next run, or promote it and skip the next run. The API and bulk promote default to the copy. Thanks to Matheus Carvalho for the report and the fix.

Bullpane is now open core. Nothing changes in the product: the free edition is still MIT and still needs no login, and Pro works exactly as before.

Changed

• Licensing. The code of the Pro features lives in the repository’s ee/ directories under the Bullpane Commercial License: you can read it, modify it and run it for development and testing, and production use needs a Pro subscription. Everything else stays MIT. Releases up to 0.3.0 remain MIT in full.

Added

• BULLPANE_CONNECTIONS: a JSON array of Redis connections created at boot when no connection of that name exists. It never overwrites a connection edited in the UI, works in read-only mode, and a bad entry stops the boot naming the field without printing the URL.

Needs attention becomes your alert rules. Open the dashboard and the top of the Overview shows every queue breaking a rule, with the value, the window and the threshold.

Added

• Needs attention driven by alert rules (Pro). Cards read 26% failed · 15m > 10%, p95 4.2s · 15m > 2s or 674 waiting > 200. A rule without channels is dashboard only; add Slack or a webhook to be notified as well.
• Rules on every queue or a whole connection, besides one queue and a folder. The most specific rule wins per condition kind, so “5% everywhere, 30% for the importer” is two rules. Hidden queues are skipped.
• Processing time rule: p50 or p95 of the jobs completed in the window.
• A starting dashboard-only rule on new installs (failure rate above 10% over 15 minutes), and a count of queues that cannot be measured because their Workers keep no BullMQ metrics.

Changed

• Failure rules read BullMQ’s per-minute metrics directly: exact to the minute from the first evaluation, so a restart no longer leaves rules “warming up” for a whole window, and removeOnComplete never skews them.
• When a queue rule and a folder rule of the same kind cover a queue, only the queue rule judges it now.

Known limits

• Only jobs finished by Workers created with metrics: { maxDataPoints } are counted; a queue shared by a deployment without it is undercounted. A job that fails an attempt and succeeds on retry counts as completed. Processing time needs completed jobs to remain in Redis.

Added

• SSO auto-provisioning (Pro), opt-in. Turn on “Let anyone from your domains sign in” under Settings → SSO and list your company’s email domains: somebody your identity provider authenticates gets a password-less viewer account on first sign-in instead of being told to ask an admin. Off by default. The domain list is mandatory and matched exactly, unverified OIDC emails are refused, disabled accounts stay disabled, and every account created this way is recorded in the audit log as auth.sso_provisioned.

The first published version. Everything before it was development, run for months against a production Redis with millions of BullMQ jobs a day; this is the point where the dashboard is worth other people’s time.

The free edition

Everything bull-board does, with no login at all: start the container, open it, use it. No account, no first-run wizard. The header says “No login” where an account menu would be, and the server warns at boot when an open instance is reachable from outside the host. Put it behind your reverse proxy or VPN.

• Queues and jobs. Every BullMQ state, per-minute completed and failed rates from BullMQ’s own metrics counters, and an attention view for the queues that need you.
• Job pages with data as a tree or raw JSON, options, return value, stack traces, logs, progress and parent/child links. Delayed jobs say when they will run, correct after a backoff retry too.
• Flow tree per job. The real parent and child instances of a flow, bounded so a parent with 50k children returns the first slice, never 50k nodes.
• Actions. Add, retry, promote, remove and discard jobs, in bulk if you like; pause (with a reason, kept in the audit log), resume, clean, retry-all, drain and obliterate queues, with the destructive ones behind the admin role and a confirmation.
• Search inside job data, bounded and resumable so a big state never blocks Redis.
• Job schedulers per queue and across a whole connection, with next run, “next run within” windows and overdue highlighting.
• BullMQ Pro groups. Each group’s status in Pro’s own vocabulary — waiting, limited, maxed, paused — jobs waiting and how many are prioritized, active jobs against the concurrency cap, rate limit, and when a limited group returns to rotation.
• Redis health monitor. Memory, CPU, commands per second, latency, clients and keys, sampled on the server and shared across tabs.
• Command palette (⌘ K) over every queue on every connection, hidden queues, and a sidebar whose order is the same for everyone.
• Read-only mode that refuses every write, for pointing the dashboard at production before you trust it.
• BullMQ 4, 5 and 6 on Redis, Redis Cluster and Valkey, plus BullMQ Pro. The BullMQ 6 PostgreSQL backend is not supported yet.

Pro

One installation, unlimited users, USD 39/month or USD 390/year. A key turns the login on without a restart.

• Users and roles (admin, operator, viewer), enforced on every API call. Users are disabled, never deleted, so the audit history keeps its names.
• SSO over OIDC and SAML 2.0, pre-provisioned only, with a password escape hatch so a misconfigured provider cannot lock you out.
• Alerts to Slack or any webhook, per queue or per folder.
• Folders to group queues the way the team thinks about them.
• Flows: the connection-wide graph of which queue feeds which.
• Audit log: append-only, with actor, target, detail and CSV export. Job payloads are never recorded.

Performance, because that is the whole point

• No KEYS, no unbounded scans. One Lua round trip per read, pipelined per queue, every access touching a single queue’s keys so Redis Cluster works.
• Payloads are truncated inside Redis and sizes are checked before data is read. On 1 MB payloads a page of 200 jobs costs 7 ms of Redis time, a search 8 ms.
• Queue discovery finds queues with a live worker at once and covers any keyspace over successive passes.
• Writes go through the official bullmq client. Bullpane never reimplements its Lua.