NextMQ
Dashboard

Introduction

NextMQ is a fully managed BullMQ service for serverless Next.js. You write familiar Queue and Worker code; we host the queue server and run your jobs for you.

BullMQ is the job queue most apps reach for background jobs. But it assumes something impossible for serverless apps: a persistent process. To use it on Next.js you'd have to operate your own queue server.

NextMQ runs that server for you. Install the SDK, add your project keys, and write normal BullMQ code: your queues live on our managed BullMQ server, and your processors stay in your app, triggered through a signed webhook. Retries, scheduling, rate limits, and flows work by default — BullMQ's developer experience without the infrastructure.

npm install @nextmq/sdk

The code shape stays familiar#

Most producer and processor code starts as an import swap. The route and environment are the serverless pieces you add around it.

- import { Queue, Worker } from 'bullmq'
+ import { Queue, Worker } from '@nextmq/sdk'

  const emailQueue = new Queue('emails')

  const emailWorker = new Worker('emails', async (job) => {
    await sendEmail(job.data)
    return { sent: true }
  })

What you get#

  • No infrastructure. We host and scale the queue server and Redis.
  • A familiar API. Queue, Worker, and FlowProducer primitives — nothing new to learn.
  • Defaults that just work. Retries, backoff, delays, priorities, rate limits, dedup, and flows.

What you write#

  • Your queues and the processor functions that run your jobs.
  • One webhook route that auto-registers your workers and verifies every call..
  • A little config — your project keys and your app's public URL.

That's the whole surface area. Everything else is managed.

Good fits#

  • Background work in a Next.js app on Vercel or any serverless platform.
  • Media processing, AI/LLM calls, report generation, syncing to third-party APIs.
  • Anything you'd use BullMQ for — without running BullMQ's infrastructure.

Next steps#

NextQuickstart