Appearance

BullMQ queues ​

Produce, inspect, and manage BullMQ jobs over HTTPS — no Redis socket, no Lua, no separate service to register.

How it works ​

BullMQ rides on your existing Redis service. You don't register a "queue" service: point the client at the same Redis service/credentials you already use, and call queue operations.

Under the hood each operation is sent as the redis service's method bull:<op> (for example bull:add, bull:getJobCounts, bull:getSnapshot), with the queue name carried in payload.target. The proxy backend owns the only real Redis connection and the BullMQ Queue instances, runs the genuine BullMQ operation, and returns the serialized result.

Why not raw Redis commands?

BullMQ isn't a sequence of independent commands — its correctness depends on atomic Lua scripts, blocking reads, and pub/sub on a live socket, which a request/response proxy can't preserve. So we proxy BullMQ intent (add this job, give me the counts) rather than Redis commands.

The default BullMQ key prefix (bull) is used, so jobs you add here land in the same queues your own workers already consume — and snapshots reflect what those workers produce.

Quick start ​

ts
const queue = zedgi.queue('emails');
const cacheQueue = zedgi.queue('emails', 'cache'); // use credentials.redis.cache

await queue.add('send', { to: 'dev@example.com' }, { attempts: 3 });
await queue.getJobCounts();   // { waiting: 1, active: 0, completed: 0, failed: 0, ... }
await queue.getSnapshot();    // counts across all queues
python
queue = zedgi.queue("emails")
cache_queue = zedgi.queue("emails", "cache")  # use credentials["redis"]["cache"]

queue.add("send", {"to": "dev@example.com"}, {"attempts": 3})
queue.get_job_counts()   # {"waiting": 1, "active": 0, ...}
queue.get_snapshot()     # counts across all queues
http
POST /rpc HTTP/1.1
Host: dev123.zedgi.app
x-zedgi-key: zk_live_xxx
content-type: application/json

{
  "service": "redis",
  "method": "bull:add",
  "payload": {
    "target": "emails",
    "args": ["send", { "to": "dev@example.com" }, { "attempts": 3 }]
  }
}

What you can do ​

  • Produce: add
  • Inspect: getJob, getJobs, getJobCounts, count, getSnapshot, getEvents, getRecentJobsForQueue
  • Manage: pause, resume, drain, clean, removeJob, retryJob, promoteJob, obliterate, closeQueue

See the Redis API → BullMQ reference for every method and its payload.

Running workers ​

This covers producing jobs and inspecting/managing queue state — not running the processors. Your workers/consumers keep running in your own runtime against the same Redis, exactly as they do today. Adding a job here simply enqueues it for those workers to pick up.

You can also try every BullMQ command interactively from the BullMQ tab on a Redis service in the dashboard playground.