Bun 队列

Quickstart

bun add bunqueue

import { Bunqueue } from 'bunqueue/client';

const app = new Bunqueue('emails', {
  embedded: true,
  dataPath: './data/emails.db', // omit to run in-memory (lost on restart)
  processor: async (job) => {
    console.log(`Sending to ${job.data.to}`);
    return { sent: true };
  },
});

await app.add('send', { to: 'alice@example.com' });

That's it. Queue + Worker in one object, persisted to a single SQLite file. No Redis, no config, no setup. msgpackr is the only runtime dependency; cron, SQLite, S3, HTTP and WebSocket use Bun's built-ins.

One Queue, Any Language (SDKs)

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.

// Node.js / Deno / Cloudflare Workers
import { Queue, Worker } from 'bunqueue-client';

const queue = new Queue('emails', { host: 'localhost', port: 6789 });
await queue.add('welcome', { to: 'user@example.com' });

new Worker('emails', async (job) => ({ sent: true }), { concurrency: 10 });

```python

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.

import { FlowProducer } from 'bunqueue-client';

const flows = new FlowProducer({ host: 'localhost', port: 6789 });
const root = await flows.add({
  name: 'publish-release',
  queueName: 'release',
  data: { version: 'candidate-42' },
  children: [
    { name: 'unit-tests', queueName: 'checks', data: { suite: 'unit' } },
    { name: 'sdk-tests', queueName: 'checks', data: { suite: 'sdk' } },
  ],
});

console.log(
  root.job.id,
  root.children?.map(({ job }) => job.id)
);
await flows.close();

The repository records the contracts and the test strategy beside each implementation:

¹ 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.

SDK guide (all six languages) →

Workflow Engine

Multi-step orchestration with saga compensation, branching, parallel steps and human-in-the-loop signals — built on bunqueue, no new infrastructure:

import { Workflow, Engine } from 'bunqueue/workflow';

const orderFlow = new Workflow('order-pipeline')
  .step(
    'reserve-stock',
    async () => {
      await inventory.reserve();
      return { reserved: true };
    },
    {
      compensate: async () => await inventory.release(), // auto-rollback on failure
    }
  )
  .step(
    'charge',
    async () => {
      return { txId: await payments.charge() };
    },
    {
      compensate: async () => await payments.refund(),
    }
  )
  .waitFor('manager-approval', { timeout: 86_400_000 }) // human-in-the-loop
  .step('confirm', async (ctx) => {
    return { txId: (ctx.steps['charge'] as { txId: string }).txId };
  });

const engine = new Engine({ embedded: true });
engine.register(orderFlow);
const run = await engine.start('order-pipeline', { orderId: 'ORD-1' });
await engine.signal(run.id, 'manager-approval', { approved: true });

Also included: nested workflows, doUntil/doWhile loops, forEach over dynamic lists, schema validation (Zod, ArkType, Valibot or any .parse()), step timeouts, typed events, SQLite-persisted execution state.

Workflow Engine guide →