Choose how to run the queue. Both options are free, with the same core queue features.
In a terminal with Bun installed, start the included server. Keep it running.
```bash bunx bunqueue start --host 127.0.0.1 --data-path ./bunqueue.db ```This is a local process on your machine. The server is included in the MIT-licensed package.
Open another terminal. Install a client, save the example, then run it.
You should see {'Processing: hello@example.com'}. Your application and worker use the same queue name and TCP address.
Use embedded mode when your app and worker run together on Bun. The queue engine lives inside your application.
```bash bun add bunqueue ```Set embedded: true on both the queue and worker. The example keeps jobs in memory; configure SQLite persistence to recover work after a restart.
bunqueue is a free, MIT-licensed job queue for Node.js, Deno, Python, PHP, Go, Rust, Elixir and Bun. The name comes from the core engine, which runs on Bun. Your application and workers use their own runtime through an official client.
The free bunqueue server runs on Bun. Your application uses the client for its own language. Bun applications can also embed the queue directly. The server, clients and queue features are included under MIT.
Create a queue, add jobs, process them with a Worker, and turn on persistence. On Bun everything runs embedded in a single process with zero configuration; from any other language, start the server once and connect.
bunqueue ships a built-in MCP server, so AI agents like Claude and Cursor can add jobs, schedule crons and monitor queues by talking to it. One command to connect, no code to write.
Six patterns you can copy into a real app: emails, webhooks, images, payments, cron and multi-step flows. Each one moves slow work out of your API request and into a background job.
Simple Mode gives you a Queue and a Worker in a single object. Add jobs, process them, add middleware, schedule crons, all from one place, one thing to close on shutdown.
Some jobs are really a sequence: reserve the stock, charge the card, send the confirmation. The workflow engine runs that sequence, retries the flaky parts, resumes after a crash, and when a later step fails it undoes the earlier ones for you.
A Queue is where work goes in. It is the same object whether it writes to SQLite in your process or talks over TCP to a memory-, SQLite-, or PostgreSQL-backed server, so client code does not change when the deployment does.
A worker is a loop you do not have to write. It asks the queue for work, runs your function, reports the outcome, and keeps the job alive while it runs.
A long, non-yielding handler can starve the code that renews its lease. Keep the broker safety mechanisms on and move computation to a thread, process, or service that cannot block them.
QueueGroup prefixes a set of queues with a shared name, so "invoices" inside the "billing" group becomes "billing:invoices". Handy for multi-tenant apps and keeping domains apart.
Some work only makes sense in order: resize every image, then build the album; charge each line, then close the invoice. A flow declares that shape once and bunqueue holds the parent until its children are done.
If a worker crashes or hangs mid-job, the job is not lost. bunqueue notices the silence, retries the job, and parks repeat offenders in the dead letter queue.
When a job runs out of retries, bunqueue can retain it in the Dead Letter Queue with the terminal error and attempt metadata, so you can inspect it and retry it deliberately.
Official client SDKs for Node.js, Deno, Bun, Python, PHP, Go, Rust, Elixir and Cloudflare Workers. Each speaks the native TCP protocol and MessagePack through an idiomatic Queue and Worker API.
Run bunqueue as a standalone service so multiple apps can share a queue. Keep one memory/SQLite broker, or point several brokers at PostgreSQL 15–18; producers and workers use the same TCP API either way.
Configure the whole bunqueue server from a single typed bunqueue.config.ts instead of scattered environment variables. Every option has IntelliSense, every section is optional.
One binary, two roles: bunqueue start runs the server, every other command talks to a running one. Push, pull, ack, DLQ, cron, backups, and monitoring, all scriptable with JSON output.
The complete environment variable reference for the bunqueue server and CLI: ports, storage, auth, TLS, S3 backup, timeouts, and logging.
The bunqueue HTTP API runs on port 6790 by default, configurable via the HTTP_PORT environment variable. All request and response bodies use JSON (Content-Type: application/json) unless otherwise noted.
A high-performance binary protocol on port 6789 by default. All messages use MessagePack encoding with length-prefixed framing, and pipelining lets the server process commands concurrently.
bunqueue is written in TypeScript and provides comprehensive type definitions. All public types are exported from bunqueue/client.
{
jobId: string;
data: P;
}
/** Emitted when a job stalls (no heartbeat) */
interface StalledEvent {
jobId: string;
}
/** Emitted when a job is removed from the queue */
interface RemovedEvent {
jobId: string;
prev: string;
}
/** Emitted when a job is moved to delayed state */
interface DelayedEvent {
jobId: string;
delay: number;
}
/** Emitted when a duplicate job is detected */
interface DuplicatedEvent {
jobId: string;
}
/** Emitted when a job is retried */
interface RetriedEvent {
jobId: string;
prev: string;
}
/** Emitted when a job enters waiting-children state */
interface WaitingChildrenEvent {
jobId: string;
}
/** Emitted when the queue has no more waiting jobs */
interface DrainedEvent {
id: string;
}
```
### QueueEvents Usage
```typescript
const events = new QueueEvents('my-queue', {
connection: { host: '127.0.0.1', port: 6789, token: process.env.BUNQUEUE_TOKEN },
});
events.on('waiting', ({ jobId }) => {
/* ... */
});
events.on('active', ({ jobId }) => {
/* ... */
});
events.on('completed', ({ jobId, returnvalue }) => {
/* ... */
});
events.on('failed', ({ jobId, failedReason }) => {
/* ... */
});
events.on('progress', ({ jobId, data }) => {
/* ... */
});
events.on('stalled', ({ jobId }) => {
/* ... */
});
events.on('removed', ({ jobId, prev }) => {
/* ... */
});
events.on('delayed', ({ jobId, delay }) => {
/* ... */
});
events.on('duplicated', ({ jobId }) => {
/* ... */
});
events.on('retried', ({ jobId, prev }) => {
/* ... */
});
events.on('waiting-children', ({ jobId }) => {
/* ... */
});
events.on('drained', ({ id }) => {
/* ... */
});
events.on('paused', () => {
/* ... */
});
events.on('resumed', () => {
/* ... */
});
events.on('error', (error: Error) => {
/* ... */
});
```
## QueueEventType
```typescript
type QueueEventType =
'waiting' | 'active' | 'completed' | 'failed' | 'progress' | 'removed' | 'drained';
```
## FlowProducer Types
### FlowProducerOptions
```typescript
interface FlowProducerOptions {
/** Use embedded mode (no server) */
embedded?: boolean;
/** TCP connection options */
connection?: ConnectionOptions;
}
```
:::note
FlowProducer extends `EventEmitter` (BullMQ v5 compatible). You can listen for
events using `.on()`, `.once()`, etc. The `close()` method returns
`Promise Nightly reports, hourly cleanups, a health ping every thirty seconds. Schedules live in the selected persistent backend: beside jobs in SQLite, or transactionally coordinated across a PostgreSQL broker fleet. Memory-only mode does not survive a restart. In SQLite mode, bunqueue stores queue state in one database file. Turn on S3 backup and the server uploads a compressed, checksummed copy on a schedule to any S3-compatible storage. PostgreSQL uses database-native backup and PITR. Cap how many jobs start per second, or how many run at the same time, so a busy queue never overwhelms the API or database behind it. A webhook is an HTTP POST that bunqueue sends to your URL when something happens to a job. Instead of polling for status, your service gets told, with a signed payload and automatic retries. Every number names the operation, persistence boundary, topology, scale, sample count and integrity check. A public on-disk add is not an internal in-memory batch, and producer ingestion is not worker drain. Benchmark results comparing the bunqueue TCP server against BullMQ with Redis on identical workloads, a feature comparison, and the cases where BullMQ is still the better pick. 54,140 vs 43,261 ops/sec Single job push 139,200 vs 44,000 ops/sec Bulk push, 100 jobs per batch 3.26 vs 4.53 ms p99 Bulk push tail latency No Redis required Embedded SQLite. One direct runtime dependency. Push ops/sec, higher is better 1.3x faster Bulk push ops/sec, higher is better 3.2x faster Bulk push p99 ms, lower is better 1.4x lower Run the default engine as one process plus SQLite, or run multiple brokers against PostgreSQL 15–18. PostgreSQL 18.6 is the pinned and recommended release. This page explains crash behavior, monitoring, and the storage-specific checks before go-live. The short version first. These rows describe the default SQLite path; PostgreSQL differences follow. This is the failure that defines a queue's honesty. Here is the exact sequence. By default bunqueue batches writes to SQLite every 10 ms for throughput. A durable write skips the application batch and commits before the add returns; host and physical-media durability remain operational concerns. In SQLite mode, the entire queue state is one database file, so disaster recovery is one object-storage snapshot. Works with AWS S3, Cloudflare R2, and MinIO; PostgreSQL uses database-native backup and PITR. Everything is on the HTTP port (default 6790). Point Prometheus at it or just curl it. PostgreSQL uses the database clock for leases and broker ownership, so host clock skew cannot create two valid owners. Schema initialization is automatic, but mixed bunqueue versions are not a supported steady state. Deploys restart the server constantly. The shutdown path is what makes that boring. The deployment guide has the Docker, systemd, and PM2 configs to paste. This page shows the smallest working way to run bunqueue in production, then ready-to-paste configs for Kubernetes, Docker, systemd, and PM2, plus health checks and backups.
Keep the zero-infrastructure SQLite engine for embedded and single-broker deployments, or opt
into PostgreSQL 15–18 when several bunqueue servers must share one authoritative queue.
Point bunqueue at a certificate and key, and all traffic between clients and the server is encrypted. No nginx or Caddy in front, one cert pair covers both the TCP and HTTP ports. The bunqueue server exposes everything a production setup needs to watch it: a Prometheus metrics endpoint, health probes for Kubernetes, ready-made alert rules, and a Grafana dashboard. Every push, pull, and ack is timed and counted automatically. You get latency histograms, live throughput rates, and structured logs without writing any instrumentation code. One pattern works everywhere: create a queue, add jobs from your HTTP handlers, process them in a worker. This page shows the smallest version, then points you to the detailed guides. Return the HTTP response now, do the slow work later. This guide wires bunqueue into Hono: enqueue from routes, process in a worker, check job status, shut down cleanly. Elysia validates request bodies before your handler runs, so jobs enter the queue already type-checked. This guide shows the Elysia-specific pieces: validated routes, the plugin pattern, and failure monitoring. This page shows how to run bunqueue on an edge gateway: turn MQTT sensor messages into persisted jobs, keep them safe while the uplink is down, and forward them to a central server when it comes back. bunqueue keeps the BullMQ Queue and Worker API. Most migrations are an import change and a deleted Redis config. This page shows the diff first, then lists every real difference. Short recipes for the tasks you hit first: retries, schedules, dedup, events, shutdown and workflows. Each one links to the guide that covers it in depth. Build a disposable PostgreSQL 18.6 cluster, run three active bunqueue brokers, and exercise the public SDK across queues, workers, events, retries, the DLQ, shared limits, and durable job graphs. A local topology that behaves like a broker fleet: private east-west traffic, unique broker identities, readiness gates, loopback-only host ports, and no bind mounts. Put producers on broker A, workers on B and C, and observers on C. PostgreSQL keeps jobs, policies, lifecycle state, events, logs, and results coherent across the fleet. Race producers through different brokers, control the queue globally, inspect failures from a peer, and retry only after the simulated payment provider is safe. Admit one atomic job graph through broker A, execute leaves through B, transform and publish through C, then read the final state and result through B. The SDK code stays ordinary. Production quality comes from stable broker identity, bounded database connections, correct traffic routing, coordinated upgrades, and rehearsed recovery. Functional evidence for the exact sources rendered in this section, including the first-run findings, final passing matrix, environment, cleanup audit, and exclusions. bunqueue has two execution topologies behind one server protocol: a synchronous sharded memory/SQLite engine, and a database-authoritative PostgreSQL 15–18 engine for multiple brokers. This section maps both and identifies which diagrams belong to which path. Flushes after 10ms or when 100 jobs are buffered, whichever comes first. The client layer provides the interface for applications to interact with bunqueue. It supports both embedded (in-process) and TCP (server) modes. Auto-batching (TCP mode, on by default): concurrent add() calls are transparently coalesced into a single PUSHB round-trip (defaults: maxSize 50, maxDelayMs 5). Sequential awaits send immediately with no penalty; durable jobs bypass the batcher and go out as individual PUSH. After each batch the worker returns to the poll loop. The memory/SQLite domain layer contains pure queue logic: no I/O, just core algorithms and data structures. PostgreSQL shares the public job model but owns ordering and coordination in database transactions. Shard count is a power of 2, based on CPU cores, max 64. The application layer orchestrates all queue operations, coordinating between the client layer and domain layer: PUSH, PULL and ACK flows, stall detection, dependency resolution, and background tasks. The authoritative priority heap and secondary ungrouped, delayed and per-group indexes change under the same synchronous shard lock. A blocked group requires no heap scan or temporary reinsertion. Processing timeouts use one next-deadline timer keyed by each active job's Why two-phase? It prevents false positives from transient delays, like a GC pause or a network hiccup. Event-based waiting, no polling: waitForJobCompletion(jobId, timeout) resolves when the 'completed' event for jobId arrives. bunqueue uses a high-performance binary protocol over TCP with MessagePack serialization and optional pipelining. This page covers the wire format, connection lifecycle, and command set. bunqueue uses SQLite with WAL mode for persistence, optimized for high-throughput job processing: batched writes, crash recovery, and S3 backups. Prepared statement cache (1-100 rows), single transaction, 50-100x faster than individual inserts. Usage: Stop the server before restore. Current compressed backups require metadata; legacy no-metadata restores are uncompressed only. The memory/SQLite engine uses a 4-ary MinHeap, skip lists, LRU caches, FNV-1a hashing, and read-write locks. PostgreSQL uses database rows, indexes, and locks for authoritative ordering and ownership. Trade-off: 4 comparisons per level vs 2. Win: better cache locality outweighs extra comparisons. Properties: probabilistic level assignment (p=0.5), expected height O(log n), simpler than balanced trees, good cache locality (sequential links). Total: O(log q + k), where q is the number of indexed jobs in that queue and k is the number returned. Removal uses the job-ID map plus a queue-local skip-list delete: O(log q). All operations: O(1). BoundedSet (FIFO): no recency tracking (faster), batch eviction removes 10% when full, amortized cost across many operations. Why bitwise AND? 3-5x faster than modulo, requires power-of-2 shard count, Memory/SQLite uses an event-driven MinHeap with lazy deletion. PostgreSQL stores shared schedules in the database and lets competing brokers lock each due row transactionally. Both use Bun's native cron parser and the same public API. The scheduler is event-driven: a precise setTimeout wakes it exactly when the next cron is due, rearmed after every add/remove/load/tick. A 60s setInterval acts only as a safety fallback against timer drift or missed events. One-paragraph answers on storage, modes, performance, retries, scaling and migration. If your question is not here, GitHub Discussions is the next stop. Symptoms, causes and fixes for the issues people actually hit: SQLite locks, embedded mode misconfiguration, stuck jobs, half-open connections and backup failures. All notable changes to bunqueue: features, fixes, performance work and breaking changes, newest first. ` in
` ` in ` ` on 33 pages. The nested paragraph also inherited the
1.75 body line-height, so hero headings rendered with a ~1.75 leading instead
of the intended 1.05 and broke across lines. All hero headings and ledes are
now single-line, and a CSS guard keeps hero typography correct if it regresses.
- Documentation site: `.bq-wrap` sits inside `.content-panel`, which already
supplies the page gutter, but added another 3rem, so every hero was inset 48px
from the prose below it. Above the 38rem phone layer every `.bq-wrap` on a
non-splash hero page now drops that inset, which also keeps pages that continue
in `.bq-wrap` sections (the production guide, the blog index) on one left edge
from hero to last section. The home splash keeps its inset.
- Quick Start: the "React to events" and Simple Mode tab groups were missing
languages while sharing `syncKey="lang"`. Starlight syncs tab sets by label,
so a reader on Rust, Elixir, PHP or Go silently fell back to the Bun tab and
was shown TypeScript. Every synced group on the page now carries the same
seven labels.
- Quick Start: the MCP setup used `bun add bunqueue` plus `bunx bunqueue-mcp`,
but the `bunqueue-mcp` binary ships inside `bunqueue` and is not a package of
its own. It now matches the MCP guide: `bun add -g` plus
`bunx --package=bunqueue bunqueue-mcp`.
- Quick Start: the Python first snippet called `Worker(...).run()` inline, so
the `worker` handle used by the later events section did not exist. It now
binds `worker` before running it.
- Documentation site: the nested-paragraph defect also affected `.bq-lede`,
`.bq-chart-title`, `.bq-vs-sum`, `.bq-bench-title`, `.bq-bench-foot` and
`.bq-pipeline-caption` blocks on the home page, the comparison page, the
production page and two blog posts. Every literal ` `/` The bunqueue security model: the defaults you get out of the box, the controls available to harden a deployment, and how to report vulnerabilities. Every statement on this page reflects the current codebase. Dev environment setup, coding standards, testing guidelines and the pull request workflow. Everything you need to land a change, whatever your experience level. Three shapes cover almost every recurring job: a fixed interval, a wall-clock time in a real timezone, and a job that re-arms itself only once the previous run finished. The expression syntax with its shortcuts, the full repeat option table with defaults and the naming each SDK uses, plus managing schedules through an AI agent. Some failures are transient. Auto-retry puts a due DLQ entry back into its queue, preserves its failure history, and stops after the configured retry budget. A DLQ that grows forever is just a leak with extra steps. These options bound it by age and by count, and decide whether entries get another chance before they expire. The four things you actually do with a Dead Letter Queue: narrow it down to the entries you care about, put a subset back, check whether the pile is growing, and empty it when the cause is fixed. What each failure reason means, what an entry actually contains once it is written, and the full list of DLQ methods with their embedded and TCP behaviour. The default is to keep waiting, which is rarely what you want. These four options let a failed child fail the parent, be ignored, cancel its siblings, or let the parent run on whatever succeeded. Four shapes cover nearly every pipeline: one after another, many at once into a single parent, a deeper tree, and the plumbing that lets a parent read what its children produced. The producer surface, what a processor can ask about its children mid-run, and the full field list of a step so you can build graphs programmatically. Short, plain-words definitions. Each term links to the guide that covers it in full. If a word in the docs is unfamiliar, it is explained here. One job or a hundred thousand, ordered by priority, held back by a delay, or written straight to disk when losing it is not an option. Namespacing so several environments can share one broker, batching that makes concurrent adds an order of magnitude faster, and draining an edge queue into a central one. The operational verbs. Stop consumption during an incident, clear a backlog, remove finished jobs before they accumulate, and push delayed work forward when you cannot wait. Retried HTTP calls, at-least-once webhooks and impatient users all produce duplicate adds. A custom id or a dedup key makes the second one a no-op instead of a second charge. The Queue object carries the DLQ surface too, so the process that produces work can also configure and drain the pile of work that failed. Put each tenant, webhook destination or customer in a group. bunqueue keeps FIFO ties inside that stream, rotates fairly across streams and enforces backpressure at the broker. Third-party APIs have quotas and databases have limits. These caps live on the queue, so they hold no matter how many workers you start. Which workers are registered, what the queue has processed, and the time-windowed counters behind a dashboard. The complete per-job option surface, what each field changes, and what you get when you leave it out. A job that runs for ten minutes should not be a black box. Progress and logs make it observable, and dependency links show how it relates to the rest of a graph. Dashboards, health checks and debugging all come down to the same questions: what is in there, what state is it in, and what did that one job actually return. The managed alternative to a repeat option buried in a job: a named schedule you can update in place and remove by id. A controlled comparison against ten preceding releases, using complete durable job lifecycles rather than isolated internal operations. Every sample includes admission, SQLite persistence, delivery, retries, result persistence and terminal-state verification. Concurrency decides how many jobs a single worker runs in parallel. Batch pulling decides how many it fetches per request. Together they set the ceiling on what one process can do. A failed attempt is not a lost job. bunqueue counts the attempt, waits a widening backoff, tries again, and only after the budget runs out does the job become permanently dead. Metrics, alerting and audit trails all hang off the same handful of events. Here is each one, when it fires and exactly what it hands your listener. The job is more than its payload: attempt counts, timestamps, progress reporting, its own log stream, and the results of any children that ran before it. Deploys are the most common cause of stalled jobs. Closing a worker properly lets in-flight jobs finish and be acknowledged before the process exits. The complete option surface for a Worker, what each one changes, and the defaults you get when you leave it alone. CPU-bound work starves an event loop. SandboxedWorker moves the handler into a worker thread so the main thread can keep heartbeating, using the same experimental worker-pool implementation on Bun, Node.js, and Deno. A crashed worker cannot tell anyone. Heartbeats let the queue notice, and lease tokens ensure only the current owner can settle a recovered job. Four agent frameworks, one integration shape. Each gives you an excellent agent loop. None gives you a way to undo what that loop did to the outside world. That is the part this page adds. An agent loop is the least durable thing in your stack. It spends real money, it changes real systems, and by default it keeps all of that in a variable that dies with the process. The builder, the engine facade, the execution shape, the fifteen event types, and an honest list of what this engine does not do. A parked run releases its worker slot and keeps its durable state in SQLite. It can sit there for a day, across a redeploy, and still pick up exactly where it left off. What is written down, what is replayed, and why a stable idempotency key is the difference between a retry and a second charge. Three steps, one rollback handler, no services to start. By the end you will have run it, broken it on purpose, and read back exactly what the engine recorded. A step that changed the outside world declares its inverse. When a later step fails, the engine runs those inverses in reverse, records every outcome, and tells you when one of them did not work. Sequences, forks, fan-out and loops. The engine journals their decisions and outcomes so completed work can be skipped and compensatable effects can be walked back. Generated from the source of each release, so the page you open documents the surface that release actually shipped, not the one on main today. A faithful in-browser model of bunqueue's memory/SQLite engine. Push jobs and watch its lifecycle, waiting to active to completed, with failures bouncing through delayed backoff until they land in the dead-letter lane.Work that runs on a clock.
The whole queue, backed up to S3.
Rate limits and concurrency, under control.
Job events, delivered as webhooks.
Benchmarks measured,
not mixed.bunqueue vs BullMQ, one less server.
1.3x Faster Push
3.2x Faster Bulk
Lower Bulk Latency
Zero Infrastructure
What survives a crash.
If it dies, what happens?
The worker dies before the ACK.
Two write modes, one decision.
One file, snapshotted to S3.
Three endpoints, no agent.
Know the recovery clock.
Treat the schema as a one-way boundary.
SIGTERM is a contract.
Before you point traffic at it.
durable: true on every job you cannot re-derive; PostgreSQL writes are
transactional without this option
jobId wherever producers retry
S3_BACKUP_ENABLED=1; PostgreSQL: provider backup/PITR; rehearse one restore
/healthz and /ready wired into your orchestrator
AUTH_TOKENS set; METRICS_AUTH if metrics are exposed
SHUTDOWN_TIMEOUT_MS sized above your longest handler
.db/.db-wal, or PostgreSQL storage/connection
alerts
lockDuration above your slowest job, or heartbeats on
Ready to deploy?
From laptop to production.
One-file SQLite. PostgreSQL for many brokers.
TLS without the reverse proxy.
Prometheus, probes, live events.
Telemetry that sees inside the process.
bunqueue in your stack.
Background jobs for Hono.
Background jobs for Elysia.
Queue at the edge, drain to the center.
BullMQ code, minus Redis.
Code examples you copy and ship.
Three brokers. One database. Real work.
PostgreSQL plus three active brokers.
N queues. N workers. One truth.
Retry safely. Recover deliberately.
Fan out. Transform. Converge.
Scale the fleet without breaking its invariants.
Tested end to end. Nothing left running.
Inside the bunqueue architecture.
Thin client, smart server.
The domain layer, no I/O.
dependencyIndex: Map<JobId, Set<JobId>>Use cases in the application layer.
startedAt + timeout. Far-future timers are safely chunked at the runtime ceiling; failed timeout transitions are logged and retried.Frames on the wire.
WAL mode and write buffers.
journal_mode = WAL Write-Ahead Loggingsynchronous = NORMAL balanced safety/performancecache_size = -64000 64MB in-memory cachetemp_store = MEMORY in-memory temp tablesmmap_size = 268435456 256MB memory-mapped I/Opage_size = 4096 4KB pagesbusy_timeout = 5000 wait up to 5s on lock contentionqueue.add('job', data, { durable: true })Heaps, skip lists, LRUs.
shardIndex = fnv1a(queueName) & SHARD_MASKhash & SHARD_MASK is equivalent to hash % SHARD_COUNT.writer = true before resolving the oldest waiter; late arrivals cannot bargeOne schedule. One winning broker.
Asked, answered.
Troubleshooting, cause and fix.
Every release, documented.
` and `
` elements.** Starlight renders the frontmatter title as
the page `
`; on the 81 hero pages custom CSS hides the panel containing it, so the
keyword-bearing heading lived in a `display: none` subtree while the hero supplied a
second `
`. A `PageTitle` override keeps the real `
` on pages that actually
display it and downgrades it to a `
` to `
`.** Its nine panel titles are now `
`,
so the page no longer breaks heading order.
- **Six meta descriptions were long enough to be truncated in search results** (up to 233
characters). All 83 are now ≤160.
### Changed
- `X-Robots-Tag: noindex, follow` for the versioned TypeDoc dump under
`/reference/v
Security, hardened by default.
Contribute to bunqueue, ship a PR.
The schedules you actually need.
Every field, every option.
Retries that happen without you.
How long dead jobs stick around.
Read it, retry it, clear it.
Every reason, every field.
One child dies. Now what?
Chain it, fan it out, merge it back.
Every method, spelled out.
Every job queue term, defined.
Getting work into the queue.
Sharing a server, and leaving it.
Pause it, drain it, wipe it.
The same job, only once.
Dead jobs, from the producer side.
Fair streams, one queue.
A ceiling on how fast.
Who is connected, and how it is going.
Every option, with its default.
What a job is doing right now.
Asking the queue what it holds.
Recurring work, named.
2.9.4 removes the
completion-path wait.More at once, fewer round-trips.
When the processor throws.
What the worker tells you.
Everything the processor gets handed.
Stopping without dropping work.
Every knob, with its default.
Handlers in their own thread.
Proving the worker is still alive.
Your agent SDK, inside a transaction.
Agents that survive the restart.
Every method, every field.
Stop, and wait for a person.
Survive the restart.
Your first workflow, in one file.
Undo, in the right order.
The shapes a process can take.
Every export, per version.
{versions.map((v) => (
Version pages are keyed by `major.minor`. Patch releases share a page because, under semver, a patch cannot change the public surface.
## What is in there
The reference covers exactly the entry points the package declares in its `exports` map, so everything documented is something you can actually import:
| Import | What it holds |
|---|---|
| `bunqueue` | Server entrypoint |
| `bunqueue/client` | `Queue`, `Worker`, `Bunqueue`, `FlowProducer`, `QueueEvents`, `Forwarder` |
| `bunqueue/workflow` | `Workflow`, `Engine`, `WorkflowEmitter` |
| `bunqueue/queue` | `QueueManager`, for embedding the broker |
| `bunqueue/mcp` | The MCP server |
Types that appear in those signatures are included too, so a parameter type is a link rather than a dead end.
## Reference or guide?
They answer different questions, and the reference is the wrong place to start.
| | Use |
|---|---|
| *What does this method take and return?* | The reference |
| *How do I build X?* | [The guide](/guide/introduction/) |
| *What crosses the wire?* | [Protocol spec](/api/tcp/) |
| *What does the HTTP surface expose?* | [HTTP API](/api/http/) |
## Stability
bunqueue follows semver: a breaking change to anything reachable from the entry points above means a major release. Anything reached by deep-importing a path not in the `exports` map is internal, may change in any release, and is not covered by the reference.
The workflow engine is a Bun, in-process API. It is not part of the wire protocol and is not implemented in the Python, PHP, Go, Rust or Elixir clients, so it does not appear in their references. See [the workflow guide](/guide/workflow/) for what that means in practice.
---
# Simulator: Try bunqueue in Your Browser
Try bunqueue live in your browser: jobs flowing through priorities, retries with backoff, dead letter queues, sharding and worker concurrency.
URL: https://bunqueue.dev/simulator/
import Simulator from '../../components/simulator/Simulator.tsx';
The engine, in your browser.