Your first job in about a minute. On Bun the queue runs inside your app, with no
server to start:
bun add bunqueue
// jobs.ts
import { Queue, Worker } from 'bunqueue/client';
const queue = new Queue<{ to: string }>('emails', { embedded: true });
const worker = new Worker<{ to: string }>(
'emails',
async (job) => {
console.log('Processing:', job.data.to);
return { sent: true };
},
{ embedded: true }
);
worker.on('error', (error) => console.error(error));
await queue.add('welcome', { to: '[email protected]' });
High-performance job queue for Bun and AI agents. Memory or one-file SQLite, optional PostgreSQL 15–18 multi-broker persistence, cron, retries, DLQ, and MCP.
That's it: no Redis, no config, no setup. The worker keeps waiting for more jobs
until you stop it with Ctrl+C. The example keeps jobs in memory; pass
dataPath: './jobs.db' to the queue and the worker to persist them in one
SQLite file. msgpackr is the only runtime dependency; cron, SQLite, S3, HTTP and
WebSocket use Bun's built-ins.
Not on Bun? Run the server, connect from anywhere
Start the server with Docker (no Bun needed) or, if Bun is installed, with
bunx bunqueue start --host 127.0.0.1 --data-path ./bunqueue.db:
It starts two brokers against one database/namespace. PostgreSQL is server-only;
embedded mode keeps using memory/SQLite. Supply both Compose values when the
password changes, percent-encoding reserved characters in the URL only. MySQL
is not supported. CI validates PostgreSQL 15, 16, 17, and the pinned/recommended
18.6 release. See the
storage guide.
Docker images
All four images run the same bunqueue server with the same queue features,
protocols, and persistence options. The difference is the Linux base and the
tools available inside the container.
Starting with 2.9.5, completed releases publish to both Docker Hub
(egeominotti/bunqueue) and GHCR (ghcr.io/egeominotti/bunqueue), with matching
version, latest, and variant tags. Build references are kept on GHCR only.
Each image supports linux/amd64 and linux/arm64; Docker selects the matching
architecture automatically. You choose the distribution, not the CPU tag.
Pin a version or digest for reproducible deployments. Confirm a tag exists with
docker buildx imagetools inspect egeominotti/bunqueue:<tag> before using it.
Choose a Linux distribution with the same tags on either registry:
Variant
Version tag
Moving tag
Runtime base
Alpine (default)
2.9.20-alpine
alpine, latest
Alpine 3.22, musl
Debian
2.9.20-debian
debian
Debian 13
Debian slim
2.9.20-slim
slim
Debian 13 slim
Distroless
2.9.20-distroless
distroless
Debian 13, no shell or package manager
Which variant should I use?
Alpine is the default for a compact deployment. It uses musl and includes
a shell and the apk package manager. Choose it when you do not need Debian
tooling or glibc compatibility for additional software.
Debian uses glibc and the standard Debian base, with a shell and apt.
Choose it when familiar Debian tools and a fuller base matter more than image
size. Additional troubleshooting tools may still need to be installed.
Debian slim keeps glibc, a shell, and apt in a reduced Debian base.
Choose it when you want Debian compatibility with fewer bundled utilities.
Distroless contains the compiled server and its required runtime libraries,
without a shell or package manager. Choose it when you operate through logs,
health checks, and external debugging tools; docker exec ... sh is unavailable.
The distribution does not select a faster queue engine or unlock extra features.
All images run as a non-root user; having a package manager does not grant that
user permission to install packages at runtime.
Try a specific variant by changing only the image tag:
This example exposes the APIs only on your machine. Replace 2.9.20-alpine with
2.9.20-debian, 2.9.20-slim, or 2.9.20-distroless to choose another base.
Moving tags such as alpine follow newer releases; version tags identify a
release, while a digest pins the exact image even across base-image rebuilds.
Every variant supports both architectures, runs as UID/GID 1001:1001, and
stores SQLite data in /app/data. Unsuffixed tags such as 2.9.20 stay on Alpine.
Production images contain the compiled server and required system libraries;
development dependencies and a separate Bun installation stay out of the image.
The built-in health check uses /app/bunqueue healthcheck, including on distroless.
See the deployment guide for custom probes.
Standalone executables and network clients
Prefer a standalone executable? GitHub releases
include the Bun runtime, so no Bun or Node.js installation is needed. From 2.9.5,
the eight downloads are:
System
Architecture
Archive
Linux (glibc)
x64
bunqueue-linux-x64.tar.gz
Linux (glibc)
arm64
bunqueue-linux-arm64.tar.gz
Linux (musl / Alpine)
x64
bunqueue-linux-x64-musl.tar.gz
Linux (musl / Alpine)
arm64
bunqueue-linux-arm64-musl.tar.gz
macOS
x64 / Intel
bunqueue-darwin-x64.tar.gz
macOS
arm64 / Apple Silicon
bunqueue-darwin-arm64.tar.gz
Windows
x64
bunqueue-windows-x64.zip
Windows
arm64
bunqueue-windows-arm64.zip
Extract the archive for your operating system and architecture, and verify it
against the release's SHA256SUMS. See the
installation guide.
Then produce and process from the language you already use:
A free video course on YouTube, from your first queue to production. Each
episode follows a guide on bunqueue.dev, with chapters and English subtitles.
Zero external infrastructure by default — memory by default; one SQLite
file when local persistence is configured
PostgreSQL 15–18 multi-broker mode — PostgreSQL 18.6 is recommended;
database-authoritative claims, fenced
leases, shared limits, cron, workers, job-state/lifecycle metrics, and failover state
(tested three-broker Docker example)
BullMQ and BullMQ Pro-compatible API — Queue, Worker,
QueueEvents, FlowProducer, plus QueuePro/WorkerPro aliases, fair job
groups, native processor batches, cooperative cancellation, and Observable
results; migrating takes minutes
MCP server included — 79 primary tools; AI agents get full queue control out of the box
Everything server-side — retries with backoff, priorities, cron, rate limits, dead letter queue
Measured, operation-specific performance — 729K jobs/sec internal
in-memory batch push, 186K jobs/sec public on-disk Embedded addBulk, and
159K jobs/sec TCP PUSHB; methodology and distributions
Great for: embedded and single-server deployments, PostgreSQL-backed broker
fleets, AI agents that need a scheduler, edge/serverless spooling, and teams
that don't want to operate Redis.
Not ideal for: multi-region consensus or deployments that require MySQL as
the queue store. If you already run Redis and BullMQ works for you, keep it.
Groups support atomic maxSize admission, priority within a group, pause and
resume, manual rate limits, per-group concurrency/rate defaults, pending-job
queries, and fair round-robin claims. Native batches support minimum size,
timeout, group affinity, and selective job.setAsFailed(error). Processor
timeouts and explicit cancellation abort the second-argument AbortSignal;
Promise handlers remain cooperative, while structural Observable handlers are
unsubscribed. These contracts are identical with SQLite and PostgreSQL 15–18.
BullMQ Pro telemetry and NestJS integration are intentionally not included.
The server does all the heavy lifting. Official client SDKs share the
protocol-conformant core Queue, Worker, and Flow surface, so producers and
workers can live anywhere in your stack — add a job from TypeScript, process it
from Python. Language-specific capabilities are tracked in the
SDK guide.
Every SDK is certified against the same public
wire protocol and conformance suite.
Atomic flows, in every SDK
Every official FlowProducer resolves all job IDs and reciprocal dependency
edges locally, then sends one PUSHF command. The broker validates the complete
graph and commits it atomically, so a worker cannot observe a leaf from a
partially-created flow.
¹ The TypeScript SDK has no mutation engine. StrykerJS was removed because its
dependency graph produced every advisory the weekly audit had to answer for,
none of it reachable from the published client; the planners keep their
fast-check coverage.
Property campaigns run in the ordinary SDK gate with deterministic replay
seeds. Mutation campaigns run separately against the pure planners and
snapshot validators. Contributors can reproduce the complete isolated SDK
gate with bun run test:sandbox:sdk; language-specific commands live in each
SDK README and AGENTS.md.
bunqueue ships a native MCP server: 79 primary tools, 5 resources, 3 prompts. Agents
schedule cron jobs, push and process jobs, retry failures, set rate limits,
and read stats — no glue code. HTTP handlers let an agent register a URL and
have a worker call it for every job. Run it over stdio or Streamable HTTP, and
use the agent preset for dynamic toolsets and destructive-call confirmation.
The 79 primary tools include bounded paging, job observation and queue diagnosis;
2 scoped resource templates limit reads to a queue. Optional workflows add up to
3 tools. Dynamic discovery tools are counted separately.
bun add bunqueue @modelcontextprotocol/sdk # the MCP SDK is an optional peer
claude mcp add bunqueue -e BUNQUEUE_MCP_PROFILE=agent -- bunx --package=bunqueue bunqueue-mcp
Check configuration before connecting:
BUNQUEUE_MCP_PROFILE=agent bunx --package=bunqueue bunqueue-mcp --doctor --json.
Doctor reports readiness without opening embedded databases; startup still checks
workflow schemas. Read structured outcomes and observe final job state before
claiming success. Queue-scoped pages omit payloads by default.
For durable agent turns, use Workflow + Engine
and the optional bunqueue/agents
journal for sessions, redacted progress replay and uncertain external effects.
Session resume and queue retries still require provider idempotency and explicit
business-effect reconciliation. The repository skill
routes directly to queue, workflow, MCP and agent references.
Dashboard
A web dashboard that fully drives your server — queues, jobs, DLQ, cron,
webhooks, workers, live activity, SQLite inspector and an AI copilot. Open
source, currently in beta:
Native Ryzen 9 9950X3D, Bun 1.3.14; medians from repeated fresh processes:
Workload
Mode
Median
Persistence
Internal batched push, 1M jobs
Embedded
729,395 jobs/sec
In-memory, no dataPath
Public sustained addBulk, 50K cell
Embedded
186,384 jobs/sec
On-disk buffered SQLite
PUSHB, fresh 50K sample
TCP
158,779 jobs/sec
On-disk buffered SQLite
No-work worker drain, concurrency 50
TCP
17,256 jobs/sec
Full pull/process/ACK
Linear Workflow Engine
Embedded / TCP
2,700 / 3,187 workflows/sec
Workflow SQLite + 3 queue nodes
These operations do different work; the internal in-memory result is not an
SQLite or public-API claim. Run bun run bench, bun run bench:tcp, or
bun run bench:workflow on your hardware.
Benchmark methodology → ·
full engineering report
Disclaimer — provided as is, with no liability for lost data or money
License
MIT — provided as is, without warranty of any kind. The authors accept no liability
for lost data, lost money or any other damage arising from official or unofficial use
of bunqueue. See DISCLAIMER.md.
High-performance job queue for Bun and AI agents. Memory or one-file SQLite, optional PostgreSQL 15–18 multi-broker persistence, cron, retries, DLQ, and MCP.
이 페이지에서 Cursor, Claude Desktop, Claude Code 또는 VS Code용 stdio 설정을 복사합니다. PlugMCP 프록시가 아니라 게시자의 설치 방식을 사용합니다.
Bunqueue에 API 키가 필요한가요?
이 레코드에는 필수 환경 변수가 등록되어 있지 않습니다.
Bunqueue은(는) 어떤 전송 방식을 사용하나요?
Bunqueue은(는) stdio를 통해 로컬에서 실행됩니다.
Bunqueue은(는) 마지막으로 언제 확인되었나요?
마지막 확인: 2026-11-14. High-performance job queue for Bun and AI agents. Memory or one-file SQLite, optional PostgreSQL 15–18 multi-broker persistence, cron, retries, DLQ, and MCP.