State-gated job actions
Add and inspect jobs, promote delayed work, and update eligible job data, priority, delay or progress. DLQ retry, completed-job requeue and destructive Cancel fail closed under the v2.8.59 contract. Job Inspector →
Skip to contentThe only queue dashboard that also
MIT licenseZero-dependency npm packageStandalone binaries for 5 platformsMulti-arch Docker imageLimits documented honestly → 1 2 3 4 5 6 7 8 9 10 11 12
bunqueue dashboard
The only queue dashboard that also
runs the server
A free, open source web UI that safely operates a bunqueue server (a fast, Redis-free, Bun-native background-job queue): queues, jobs, dead-letter queue, cron, webhooks, workers and live activity, plus start / stop / restart of the server process itself. Built for Bun developers and AI-agent builders who want to operate their queue, not just watch it. It uses Bunqueue's public HTTP API plus its pinned public client/CLI behind a tiny loopback control agent, and fails closed when the v2.8.59 contract cannot make a mutation atomic.
Open the live demoQuick startGitHub
Overview
Features
Everything an operator needs to run a bunqueue server from the browser, from state-gated job actions right through to the process lifecycle. Every card below is a shipped page you can open in the demo right now.
Live activity stream
A Server-Sent-Events feed with automatic reconnect shows jobs flowing in real time. It is built on fetch, so it works with bearer-token auth, unlike EventSource. Live logs →
DLQ triage
A fleet-wide dead-letter dashboard plus a single-queue triage surface: failure reasons, per-attempt history and CSV export. Manual, bulk and Copilot retry remain unavailable because the GET + POST sequence has no atomic generation/state/topology precondition; purge is disabled too. DLQ Control →
Cron manager
Schedule by cron expression or interval-in-ms with a next-runs preview, then list and delete existing schedules. Cron →
Webhooks
Register endpoints with event scoping and an optional HMAC secret; watch success/failure counts, toggle, delete. Webhooks →
Server lifecycle
The one thing HTTP can't do, namely starting, stopping and restarting the bunqueue process, is delegated to a small loopback-bound agent with an Origin + Host allowlist, locked CORS and an optional bearer token. Server Control →
SQLite inspector
Browse tables, schema and indexes, page through rows, run SELECT-only queries with EXPLAIN and CSV/JSON export, all over a read-only connection, capped at 500 rows. Database →
Metrics & throughput
Rolling live throughput charts, error-rate gauge, per-operation latency percentiles (push / pull / ack × p50 / p95 / p99). Metrics →
Client-side alerts
Threshold rules on queue depth, failures, error rate and latency, evaluated in the browser, with in-app toasts and desktop notifications. Alerts →
Benchmark
Push and drain load runs against any queue, in count or duration mode, with a live chart and run history. Benchmark →
Flow DAG viewer
Explore parent/child/dependency DAGs, create every official FlowProducer shape, and operate safe Flow Job methods. Job Flows →
AI Copilot experimental
An in-app assistant that reads the same API through tools; its only mutations are Promote, Pause and Resume, each confirmed by you. Bring your own key, and requests go straight from your browser to your provider. Copilot →
Tour
See it in action
A real control surface, not a read-only viewer, so every screen in this tour is a live page you can drive in the demo.
Surface
Everything you can drive
Queuespause · resume · desired-state limits · flow-safe controlsJobsadd · inspect · promote · guarded metadata editsDLQreasons · attempt history · CSV · read-only retry controlsCronexpressions or intervals · next-runs previewWebhooksevent scoping · HMAC secrets · delivery statsWorkershealth · last seen · stale-record cleanupServerstart · stop · restart · live process logsDatabaseread-only SQLite tables · schema · queries
Process
Up and running in four steps
The priority is simplicity: one command serves the dashboard, proxies the API and runs the control agent. No clone, no build.
Step 1
Run it
One process serves the dashboard on http://127.0.0.1:8080, proxies /api/* to your bunqueue server and runs the control agent.
bash
bunx bunqueue-dashboardStep 2
Point it at your server
Set the server URL and bearer token from the Settings page (tokens stay in memory, never written to localStorage) or via BUNQUEUE_URL / VITE_BUNQUEUE_URL.
Step 3
…or let it run the server for you
From Control ▸ Server the agent starts, stops and restarts the bunqueue process, with an editable launch config and a colour-coded live log tail.
Step 4
Drive it
Explore jobs, triage the DLQ, schedule cron, watch live activity. Destructive actions are confirmed and name their target; everything else is one click.
Get started
How to install
Four ways to run it, pick the one that fits. All of them serve the same app.
bash
bunx bunqueue-dashboard
# → http://127.0.0.1:8080, serves the SPA plus the /api proxy and control agentbash
# Download the binary for your platform from the GitHub Releases page,
# then make it executable and run it, nothing else to install:
chmod +x bunqueue-dashboard-v*-darwin-arm64
./bunqueue-dashboard-v*-darwin-arm64
# → http://localhost:8080bash
docker run --rm -p 8080:80 ghcr.io/egeominotti/bunqueue-dashboard:edge
# → http://localhost:8080, set the server URL from the Settings pagebash
bun install
bun start
# agent (http://127.0.0.1:6800) + dashboard (http://localhost:5273) togetherFAQ
Frequent questions
What is this, and why not just curl the API?
A complete operator surface over bunqueue's HTTP API: scheduling, triage, limits, live activity and process lifecycle in one UI, with every job action gated by the job's real state, instead of hand-rolled curl scripts and guesswork about which action a job will accept.
Does it touch my server's code or data?
No. It never modifies Bunqueue. Ordinary operations use the public HTTP API; Flow and Workflow controls use the pinned public client through the loopback agent. Source-mode backup controls invoke the installed CLI, while the standalone executable embeds that same pinned backup command in an isolated worker so it never recursively launches itself. The compile and E2E gates make any internal CLI layout drift fail visibly during an upgrade. The SQLite inspector opens its own read-only connection and accepts SELECT-style statements only, so it cannot write even if asked to.
Is the control agent safe to run?
The agent can spawn processes, so it's locked down: a direct loopback listener, an Origin allowlist with CORS never set to *, and a Host-header allowlist against DNS rebinding. Truly local access can remain zero-config; a LAN or reverse-proxied /agent bridge requires AGENT_TOKEN on every route, while the all-in-one /api proxy separately requires BUNQUEUE_TOKEN. The full threat model is in the agent docs.
Where do my tokens and secrets live?
In memory only. Server tokens, agent tokens, S3 keys and webhook targets are deliberately excluded from localStorage, so re-enter them per session or use authentication at your front proxy. Never put secrets in VITE_* variables: they become plaintext in the public bundle.
Can I try it without a bunqueue server?
Yes, the live demo runs the real app against fixture data in your browser. Every page works, no backend required.
How do I deploy it?
Four ways: the prebuilt npm package (bunx bunqueue-dashboard), a standalone binary for linux/macOS/windows, the multi-arch Docker image, or from source. The binary embeds the SPA, the API proxy and the agent in one file.
What doesn't it do?
Alerts are evaluated in the browser while a tab is open, so it's not away-from-desk paging. S3 credentials remain session-only even though configuration and operations are available in the UI. Mutations that v2.8.59 cannot make atomic are intentionally disabled, including every DLQ retry and completed-job requeue. DLQ maxAge/maxEntries are shown read-only and omitted from saves; auto-retry can only be disabled. Every verified contract gap is listed on the known issues page.
Is my data sent anywhere?
No telemetry. The only optional egress is the AI Copilot: if you enable it, requests go directly from your browser to the LLM provider you configure, using your own key.