Workbench is a free, open source messaging & event streaming project written in TypeScript and released under MIT. It has 442 GitHub stars, 43 forks and 31 open issues, and was last pushed 4 months ago. On this registry it ranks #8 of 8 tracked projects in Messaging & Event Streaming, with 5 head-to-head comparisons available. It gained 3 stars over the last 6 tracked days.

What is Workbench?

Workbench is an open-source, MIT-licensed dashboard for BullMQ that lets Node.js and Bun teams inspect, debug, and replay Redis-backed job queues from inside their own backend, behind their own authentication.

What it is

Workbench is a TypeScript dashboard for BullMQ, the Redis-backed job queue library for Node.js. It runs jobs, flows, schedulers, and metrics and serves them directly from your own backend rather than from a separate service. It can mount as a route inside an existing application or run as a standalone Docker container, so the queue UI lives on the same origin and under the same auth as the rest of your stack. The project ships thirteen first-party framework adapters covering Hono, Elysia, Express, Fastify, Koa, NestJS, AdonisJS, Next.js, TanStack Start, Astro, Nuxt, Bun.serve, and h3.

The concrete problem it solves is the operational gap left by bull-board, the incumbent BullMQ dashboard it is positioned as a drop-in replacement for. Bull-board gives a read-oriented view of queues; Workbench adds FlowProducer DAG visualisation, schedulers, error triage, search, and a keyboard-driven interface, and wraps the whole thing in a dark-mode UI that is basic-auth-protected by default. Because it mounts into the host application, there is no second deployment to secure, no cross-origin configuration, and no separate credentials to manage — the dashboard inherits the surrounding app's routing and auth boundary.

Key capabilities

  • Thirteen framework adapters published as scoped packages, including @getworkbench/hono, @getworkbench/express, @getworkbench/fastify, @getworkbench/koa, @getworkbench/nestjs, @getworkbench/h3, and @getworkbench/elysia.
  • A FlowProducer DAG view for visualising parent and child job relationships, alongside metrics, schedulers, and search.
  • A CLI, npx @getworkbench/cli init, that detects your framework, installs the matching @getworkbench/* package, injects the mount point (or scaffolds a route file for Next.js), writes .env.example entries, and optionally drops a docker-compose.yml for Redis.
  • A standalone image at ghcr.io/workbench-standalone for Docker and Kubernetes deployments where mounting into an app is not practical.
  • An MCP server for Cursor, Claude Desktop, Zed, and Continue.dev, allowing queues to be driven from an editor's chat.
  • A dark-mode UI protected by basic auth by default, requiring no additional authentication layer to stand up.

Who uses it and how

  • Teams already running BullMQ inside an Express, Fastify, NestJS, Hono, or Elysia backend who want a queue UI on the same origin rather than a separate service.
  • Docker and Kubernetes operators who deploy the ghcr.io/workbench-standalone image as an independent container.
  • Developers using AI-assisted editors who drive queue operations through the MCP server from chat.
  • Teams migrating off bull-board, who can swap the mount in one command and keep the same backend.

Getting started

Run npx @getworkbench/cli init; the CLI detects your framework, installs the matching package, and wires up the mount. For manual setup, install the adapter that matches your stack — for example npm i @getworkbench/hono bullmq hono — and register the workbench() handler.

How it compares

Among the tools named in the facts, the direct point of comparison is bull-board, the dashboard Workbench is designed to replace; Workbench maps each bull-board adapter to a @getworkbench/* equivalent, such as @bull-board/express to @getworkbench/express. Workbench differentiates on FlowProducer DAG support, error triage, schedulers, search, and a keyboard-driven UI. No paid products are listed as being replaced.

When to use it — and when not to

A self-hoster must operate Redis, since BullMQ depends on it, and the CLI can scaffold a docker-compose.yml to make that local setup easier. Teams that do not use BullMQ, or that want a fully hosted dashboard with no infrastructure of their own, should look elsewhere. The project carries 31 open issues, so prospective adopters should weigh the current issue backlog and release cadence before standardising on it.

project readme (upstream, from github) — read inline

Workbench — the missing dashboard for BullMQ

Workbench

Open-source BullMQ dashboard. Drop-in for any Node or Bun backend.

Workbench is a modern dashboard for BullMQ. Runs jobs, flows, schedulers and metrics, all served from your own backend behind your own auth.

  • Zero infrastructure — mounts as a route in your existing app, or run as a standalone Docker container
  • Adapters for Hono, Elysia, Express, Fastify, Koa, NestJS, AdonisJS, Next.js, TanStack Start, Astro, Nuxt, Bun.serve, and h3
  • Standalone image on GHCR (ghcr.io//workbench-standalone) for Docker / Kubernetes deployments
  • MCP server for Cursor, Claude Desktop, Zed, and Continue.dev — drive your queues from your editor's chat
  • Flows & DAG view, metrics, schedulers, search
  • Dark-mode UI, basic-auth-protected by default
  • MIT licensed

Website: getworkbench.dev · Documentation

Migrating from bull-board?

Workbench is a drop-in alternative with thirteen first-party framework adapters, FlowProducer DAGs, error triage, and a keyboard-driven UI.

bull-board Workbench
@bull-board/express @getworkbench/express
@bull-board/fastify @getworkbench/fastify
@bull-board/koa @getworkbench/koa
@bull-board/nestjs @getworkbench/nestjs
@bull-board/hono @getworkbench/hono
@bull-board/h3 @getworkbench/h3
@bull-board/elysia @getworkbench/elysia

Run npx @getworkbench/cli init to swap the mount in one command. Full comparison: getworkbench.dev/blog/workbench-vs-bull-board

Quick start

npx @getworkbench/cli init

The CLI detects your framework, installs the matching @getworkbench/ package, injects the mount (or scaffolds a route file for Next.js), writes .env.example entries, and optionally drops a docker-compose.yml for Redis.

Manual setup

Pick the adapter that matches your stack:

Hono
npm i @getworkbench/hono bullmq hono
import { Hono } from "hono";
import { Queue } from "bullmq";
import { workbench } from "@getworkbench/hono";

const app = new Hono();
const emailQueue = new Queue("email", { connection: { url: process.env.REDIS_URL! } });

app.route("/jobs", workbench({ queues: [emailQueue] }));

export default app;
Elysia
bun add @getworkbench/elysia bullmq elysia
import { Elysia } from "elysia";
import { Queue } from "bullmq";
import { workbench } from "@getworkbench/elysia";

const emailQueue = new Queue("email", { connection: { url: process.env.REDIS_URL! } });

new Elysia()
  .mount("/jobs", workbench({ queues: [emailQueue], basePath: "/jobs" }))
  .listen(3000);
Express
npm i @getworkbench/express bullmq express
import express from "express";
import { Queue } from "bullmq";
import { workbench } from "@getworkbench/express";

const app = express();
const emailQueue = new Queue("email", { connection: { url: process.env.REDIS_URL! } });

app.use("/jobs", workbench({ queues: [emailQueue] }));
app.listen(3000);
Fastify
npm i @getworkbench/fastify bullmq fastify
import Fastify from "fastify";
import { Queue } from "bullmq";
import { workbench } from "@getworkbench/fastify";

const app = Fastify();
const emailQueue = new Queue("email", { connection: { url: process.env.REDIS_URL! } });

await app.register(workbench({ queues: [emailQueue] }), { prefix: "/jobs" });
await app.listen({ port: 3000 });
NestJS
npm i @getworkbench/nestjs bullmq
import { NestFactory } from "@nestjs/core";
import { Queue } from "bullmq";
import { workbench } from "@getworkbench/nestjs";
import { AppModule } from "./app.module";

async function bootstrap() {
  const app = await NestFactory.create(AppModule);

  const emailQueue = new Queue("email", { connection: { url: process.env.REDIS_URL! } });

  await workbench(app, "/jobs", { queues: [emailQueue] });

  await app.listen(3000);
}
bootstrap();

Works on both the Express (default) and Fastify NestJS platforms.

AdonisJS
npm i @getworkbench/adonis bullmq @adonisjs/core
// start/routes.ts
import router from "@adonisjs/core/services/router";
import { Queue } from "bullmq";
import { mountWorkbench } from "@getworkbench/adonis";

const emailQueue = new Queue("email", { connection: { url: process.env.REDIS_URL! } });

mountWorkbench(router, "/jobs", { queues: [emailQueue] });

Works with AdonisJS 6 and 7. See examples/with-adonis.

Next.js (App Router)
npm i @getworkbench/next bullmq
// app/jobs/[[...workbench]]/route.ts
import { Queue } from "bullmq";
import { workbench } from "@getworkbench/next";

const emailQueue = new Queue("email", { connection: { url: process.env.REDIS_URL! } });

export const { GET, POST, PUT, PATCH, DELETE } = workbench({
  queues: [emailQueue],
  basePath: "/jobs",
});

Next doesn't host BullMQ workers itself — run them in a sibling process. See examples/with-next.

TanStack Start
npm i @getworkbench/tanstack-start bullmq @tanstack/react-start
// src/lib/workbench-handlers.ts
import { Queue } from "bullmq";
import { workbench } from "@getworkbench/tanstack-start";

const emailQueue = new Queue("email", { connection: { url: process.env.REDIS_URL! } });

export const workbenchHandlers = workbench({
  queues: [emailQueue],
  basePath: "/jobs",
});
// src/routes/jobs.ts
import { createFileRoute } from "@tanstack/react-router";
import { workbenchHandlers } from "../lib/workbench-handlers";

export const Route = createFileRoute("/jobs")({
  server: { handlers: workbenchHandlers },
});
// src/routes/jobs/$.ts
import { createFileRoute } from "@tanstack/react-router";
import { workbenchHandlers } from "../../lib/workbench-handlers";

export const Route = createFileRoute("/jobs/$")({
  server: { handlers: workbenchHandlers },
});

Register handlers on both /jobs and /jobs/$ so the bare mount and nested paths work. TanStack Start doesn't host BullMQ workers itself — run them in a sibling process. See examples/with-tanstack-start.

Koa
npm i @getworkbench/koa bullmq koa
import Koa from "koa";
import { Queue } from "bullmq";
import { workbench } from "@getworkbench/koa";

const app = new Koa();
const emailQueue = new Queue("email", { connection: { url: process.env.REDIS_URL! } });

app.use(workbench({ queues: [emailQueue], basePath: "/jobs" }));
app.listen(3000);

Koa has no built-in mount helper — pass basePath so the middleware can match its own prefix and forward everything else to the next middleware.

Astro
npm i @getworkbench/astro bullmq
// src/pages/jobs/[...workbench].ts
import { Queue } from "bullmq";
import { workbench } from "@getworkbench/astro";

const emailQueue = new Queue("email", { connection: { url: process.env.REDIS_URL! } });

export const { GET, POST, PUT, PATCH, DELETE, prerender } = workbench({
  queues: [emailQueue],
  basePath: "/jobs",
});

Astro must be in server output mode (output: "server" or "hybrid"). Astro doesn't host BullMQ workers itself — run them in a sibling process. See examples/with-astro.

Nuxt
npm i @getworkbench/nuxt bullmq
// server/routes/jobs/[...].ts
import { Queue } from "bullmq";
import { workbench } from "@getworkbench/nuxt";

const emailQueue = new Queue("email", { connection: { url: process.env.REDIS_URL! } });

export default workbench({
  queues: [emailQueue],
  basePath: "/jobs",
});

Nuxt's server runtime (Nitro / h3) doesn't host BullMQ workers itself — run them in a sibling process. See examples/with-nuxt.

Bun.serve
bun add @getworkbench/bun bullmq
import { Queue } from "bullmq";
import { workbench } from "@getworkbench/bun";

const emailQueue = new Queue("email", { connection: { url: process.env.REDIS_URL! } });

readme truncated — read the full docs on github

Frequently asked questions

Is Workbench free to use?

Workbench is open source under the MIT licence. There is no licence fee and no seat count — you can self-host it or, where the project offers one, pay a vendor for a managed version instead.

What does Workbench do?

Inspect, debug, and replay BullMQ queues visually

What is Workbench written in?

Workbench is primarily written in TypeScript. Its source is publicly available at https://github.com/pontusab/workbench, and it has 442 GitHub stars.