# bee-queue: a Redis-backed job queue for Node.js short jobs

> bee-queue is a small Node.js job queue on Redis, built for short real-time jobs that finish inside an HTTP request. It is fast and simple, but it has no job prioritization or repeatable jobs, so BullMQ or Kue stay the better fit for heavy background pipelines.

**bee-queue/bee-queue** — A simple, fast, robust job/task queue for Node.js, backed by Redis.

- Repository: https://github.com/bee-queue/bee-queue
- Stars: 4,036 · Forks: 221
- Language: JavaScript
- License: NOASSERTION
- Published: 2026-09-23 · Updated: 2026-09-23 · Language: en
- Canonical page: https://hysenlabs.com/projects/bee-queue-bee-queue

## What bee-queue solves, and who it is for

bee-queue exists for one shape of work: short, real-time jobs inside a distributed worker pool. The README describes the intended pattern directly: a web server enqueues a job, a worker process completes it, and the result comes back within an HTTP request. Scaling means running more workers, not rearchitecting the queue.

The author's stated motivation is narrow and honest. They wanted to combine Bull's simplicity and robustness with Kue's ability to send events back to job creators, then cut overhead. The README says Bee-Queue "compromises on breadth of features," and names the cases where Kue or Bull may be preferable. That is a useful signal: this is not a general-purpose background job platform. It is a small library for teams whose jobs finish quickly and whose bottleneck is Redis round trips, not feature coverage. If your jobs run for minutes, or you need cron-style scheduling, the README points you elsewhere.

## How the Redis-backed queue works under the hood

The mechanism is Redis plus Lua. According to the README, bee-queue uses Lua scripting and pipelining to minimize network overhead, and it "strives for all atomic operations." Jobs are stored in Redis; workers pull them and process them concurrently.

Two design choices matter for correctness. First, the queue retries stuck jobs, which the README frames as at-least-once delivery. That means a worker that dies mid-job can have its work re-run, so handlers should be written with that in mind. Second, events travel over Redis Pub/Sub: progress reporting and job results are sent back to producers this way. Pub/Sub is fire-and-forget, so a producer that is not subscribed when the event fires will miss it.

The public surface is deliberately small. Queues are objects created with a name; jobs are created with Queue.createJob(data) and saved with .save(). The API is callback- and Promise-compatible, and the README notes the library is around 1000 LOC with minimal dependencies. The package.json lists three runtime dependencies: p-finally, promise-callbacks and redis.

## Installing bee-queue and processing your first job

Installation is one npm command. The README also states you need Redis running somewhere, and recommends Redis 3.2+ because some jobs were delayed by an issue with Redis below 3.2.

```bash
npm install bee-queue
```

After that, create a queue and a job. The README's opening example creates a queue named "example", saves a job carrying {x: 2, y: 3}, and listens for the succeeded event on the job object.

```js
const Queue = require('bee-queue');
const queue = new Queue('example');

const job = queue.createJob({x: 2, y: 3});
job.save();
job.on('succeeded', (result) => {
  console.log(`Received result for job ${job.id}: ${result}`);
});
```

Processing runs in a separate worker process. The README's process handler receives the job and a done callback, and returns the result through done(null, ...).

```js
queue.process(function (job, done) {
  console.log(`Processing job ${job.id}`);
  return done(null, job.data.x + job.data.y);
});
```

Jobs also expose a chaining API for configuration before saving. The README shows .timeout(3000) and .retries(2) applied before .save(), with the promise resolving once the job is enqueued and job.id is populated.

```js
const job = queue.createJob({x: 2, y: 3});
job
  .timeout(3000)
  .retries(2)
  .save()
  .then((job) => {
    // job enqueued, job.id populated
  });
```

Queues are lightweight, so the README suggests instantiating one per job type. A settings object can point a queue at another Redis host and mark it as producer-only with isWorker: false.

```js
const subQueue = new Queue('subtraction', {
  redis: {
    host: 'somewhereElse',
  },
  isWorker: false,
});
```

## What bee-queue deliberately leaves out

The README is explicit that bee-queue currently does not support job prioritization or repeatable jobs. Those are exactly the features Celery, Resque, Kue and Bull provide, and the README says those libraries are generally designed for longer background jobs. If your workload needs a priority lane for urgent work, or a job that fires on a schedule, bee-queue is the wrong tool and the project says so.

There is a second boundary worth naming. At-least-once delivery via stuck-job retries means a job can run more than once. For idempotent work such as sending a notification or recomputing a value, that is acceptable. For work with side effects that cannot be repeated safely, the retry behaviour is a hazard, not a feature. The README does not document rollback, so partial completion is something your handler has to reason about.

A third constraint is operational rather than conceptual: Redis is a dependency, not an option. There is no in-process or SQL-backed mode, so the queue inherits Redis availability as part of your system's availability.

## bee-queue compared with BullMQ and Kue

The difference is scope, not quality. BullMQ and Kue carry broader feature sets: the README names prioritization and repeatable jobs as things bee-queue does not currently support, and those libraries do. Bee-Queue's own motivation section says it compromises on breadth of features, so choosing it is choosing a smaller surface in exchange for less overhead per job.

Concretely: if you need a delayed job that runs every night, or a queue where high-priority jobs jump ahead of low-priority ones, you will be building that on top of bee-queue rather than configuring it. If your jobs are short, your throughput is limited by Redis chatter, and you want results back inside the request that created the job, bee-queue's focus is the point.

There is also an ecosystem difference. The README points to Arena, a separate web interface for managing jobs and inspecting queue health. That is a companion project, not part of the library, so plan for it as a separate deployment if you want a UI.

## Version 2.0.0, licence and upgrade cost

The repository shows v2.0.0 released on 2025-12-08, after a long gap from v1.7.1 in 2023. The last push to the default branch was on 2026-09-23. The project is not archived, and the README credits Mixmax for resuming maintenance.

Upgrade cost depends on how much of the API you touch. The runtime dependency list is short (p-finally, promise-callbacks, redis), and the package ships index.js, index.d.ts and lib, so TypeScript users get types from the published package rather than a separate @types install. That is a small surface to audit across a major version, but the README does not include a migration guide for 1.x to 2.x, so treat the changelog as the source to check.

The licence is marked NOASSERTION in the repository metadata, which means the automated classifier could not map the LICENSE file to a known SPDX identifier. Read the LICENSE file in the repository before you ship it in a product, and let your own legal review decide. Nothing here is legal advice.

## Conclusion

Adopt bee-queue when your jobs are short, your workload fits a Redis-backed worker pool, and you do not need prioritization or repeatable jobs. Do not adopt it if you need those features, because the README says it currently does not support them. Before committing, run npm install bee-queue against Redis 3.2+ and verify that the timeout, retries and stalled-job behaviour match your failure model, since the README does not document rollback for partially completed work.

## FAQ

### What are some alternatives to BullMQ?

The README names Celery, Resque, Kue and Bull as libraries that operate similarly to bee-queue, and says they are generally designed for longer background jobs with features such as job prioritization and repeatable jobs that bee-queue currently does not support.

### What is a queue in coding?

In this project a queue is the object you create with a name, such as new Queue('addition'), which stores jobs in Redis and hands them to worker processes. The README describes queues as very lightweight, with the only significant overhead being the connection to Redis.

### How do I install bee-queue and what does it need?

Install it with npm install bee-queue. You also need Redis running somewhere; the README recommends Redis 3.2+ because some jobs were delayed by an issue with Redis below that version.

## Sources

- [bee-queue/bee-queue on GitHub](https://github.com/bee-queue/bee-queue)
- [Issues](https://github.com/bee-queue/bee-queue/issues)
- [README](https://github.com/bee-queue/bee-queue/blob/master/README.md)
- [Releases](https://github.com/bee-queue/bee-queue/releases)

---

Hysen Labs editorial analysis, written from the project's own repository and release notes. Cite the canonical page: https://hysenlabs.com/projects/bee-queue-bee-queue