Process jobs at any scale, no Redis cluster required

The problem

BullMQ is the standard for Node.js job queues. But it needs Redis. So now you're managing a Redis instance (or paying for Upstash, ElastiCache, or Redis Cloud) just for queues. Then you need Bull Board or a custom dashboard to actually see what's happening inside those queues. Then alerting when jobs fail silently at 3am. You're maintaining three separate pieces of infrastructure for what should be simple: run this function later. And if your queue throughput needs to grow, you're looking at Redis Cluster, which means slot migration, cross-slot errors, and a whole new category of operational pain.

Without Lux

Four pieces of infrastructure for something that should just work.

With Lux

Point BullMQ-compatible workloads at your Lux connection string and keep queues close to the rest of your app state.

Get started in 30 seconds

import { Queue, Worker } from "bullmq"

const connection = {
  host: "your-project.db.luxdb.dev",
  port: 6380,
  password: "database-password",
  tls: {}
}

const emailQueue = new Queue("emails", { connection })

await emailQueue.add("welcome", {
  to: "user@example.com",
  template: "welcome"
})

const worker = new Worker("emails", async (job) => {
  await sendEmail(job.data.to, job.data.template)
}, { connection })

If you already use BullMQ with Redis, the only change is the connection object.

How it works

Lux is Redis-compatible at the protocol level. BullMQ uses Redis lists, sorted sets, and Lua scripts internally to manage job lifecycle. Lux supports all of these, so BullMQ works with zero code changes. Point your Queue and Worker constructors at your Lux connection string and everything just works. No adapter, no wrapper library, no compatibility mode.

Lux keeps queue state in the same managed project as your app data, logs, metrics, and connection surface. The near-term product direction is clear operational visibility from the dashboard without deploying a separate queue admin service.

BullMQ's job lifecycle involves multiple Redis commands per job (ZADD, RPUSH, BRPOPLPUSH, etc.). Lux's multi-threaded Rust engine can process independent queue operations across cores, which is why queue-like workloads are a natural fit for the engine.

Migration is a five-minute task. Spin up a Lux Cloud instance, update your connection config, deploy. If you're running delayed jobs or rate-limited queues, those work too. Lux handles the sorted set operations that BullMQ uses for job scheduling with full fidelity.

Advanced patterns

import { Queue, Worker, QueueScheduler } from "bullmq"

const connection = {
  host: "your-project.db.luxdb.dev",
  port: 6380,
  password: "database-password",
  tls: {}
}

const invoiceQueue = new Queue("invoices", { connection })
const reportQueue = new Queue("reports", { connection })

await invoiceQueue.add("generate", { userId: "usr_123" }, {
  delay: 60000,
  attempts: 3,
  backoff: { type: "exponential", delay: 5000 }
})

await reportQueue.add("weekly-summary", {}, {
  repeat: { pattern: "0 9 * * MON" }
})

const invoiceWorker = new Worker("invoices", async (job) => {
  const pdf = await generateInvoice(job.data.userId)
  await uploadToS3(pdf)
}, {
  connection,
  concurrency: 10,
  limiter: { max: 100, duration: 60000 }
})

Delayed jobs, exponential backoff, cron repeats, concurrency limits, and rate limiting. All powered by Lux.

Feature deep-dive