The BullMQ you know,
fully managed for Next.js.

Drop in the same Queue and Worker API you already use. NextMQ hosts the queue server and Redis, auto-manages your webhook endpoint, and handles retries, scheduling, and rate limits by default — so background jobs just work on serverless. No infra to run.

Start free →Read the quickstart

$npm install @nextmq/sdk

How a job flows

Your Next.js app

Pages

Route handlers

Server actions

NextMQ SDK

BullMQ-API-compatible

HTTPSboth ways

NextMQ

BullMQ server

real workers

Redis

jobs & state

The BullMQ-API-compatible SDK lives in your app and talks to NextMQ over HTTPS. We run the server and Redis for you.

Works withNext.jsBullMQVercelTypeScript

Why NextMQ

Running BullMQ on serverless is a project.
We made it a dependency.

BullMQ needs a process that stays alive and a live Redis connection. Serverless Next.js has neither — so you'd end up running and babysitting infrastructure. NextMQ runs all of it for you.

On your own

Stand up and scale a queue server
Provision, secure, and patch Redis
Keep a worker process alive 24/7
Hand-wire webhook routing & signatures
Reconnect on every cold start

With NextMQ

npm install @nextmq/sdk
Paste your project keys
Write the same BullMQ you already know
Add one route — we auto-manage it
We host, scale, and monitor the rest

How it works

Three steps.
Then forget it's there.

Add your keys

Install @nextmq/sdk and drop in the project keys from your dashboard. That's the setup.

Write normal BullMQ

The same Queue, Worker, and FlowProducer API. Nothing new to learn, nothing to configure.

We run everything

Your jobs execute on our managed BullMQ and call your code back over a signed webhook — with retries, scheduling, and rate limits built in.

Fully managed

The infrastructure
you never set up.

Everything that makes BullMQ hard on serverless lives on our side of the line. You ship features; we keep the queue running.

Running or scaling a queue server
Provisioning and patching Redis
Keeping a long-lived worker process alive
Wiring webhook routing, signatures & retries
Reconnecting to Redis on every cold start
Monitoring queue infrastructure

Drop-in

If you know BullMQ,
there's nothing to learn.

It's the same Queue, Worker, and FlowProduceryou already write — pointed at a managed server instead of a Redis you operate. Add one route handler and you're done.

See the full quickstart →

jobs/media.ts

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

// A normal BullMQ queue — except it runs on NextMQ's managed server.
// No Redis to provision, no worker process to keep alive.
const media = new Queue<{ uploadId: string }>('media')

export const mediaWorker = new Worker('media', async (job) => {
  await job.updateProgress(20)
  const { url } = await transcode(job.data.uploadId) // your long task
  return { url }
})

// Enqueue from a route or server action.
// Retries, backoff and scheduling are handled for you.
await media.add('transcode', { uploadId }, {
  attempts: 5,
  backoff: { type: 'exponential', delay: 1000 },
})

route.ts

// app/api/nextmq/[...path]/route.ts — the only wiring you add.
import { createNextMQHandler } from '@nextmq/sdk/next'
import { mediaWorker } from '@/jobs/media'

export const runtime = 'nodejs'

// NextMQ auto-registers your workers and verifies every signed call.
export const { GET, POST } = createNextMQHandler({ workers: [mediaWorker] })

Handled by default

The full BullMQ feature set,
running where it belongs.

Every control that makes BullMQ worth using is on by default — managed on our server, available through the API you already know.

Retries & backoff

Throw from your handler and NextMQ retries with fixed or exponential backoff. The retry schedule lives on our server, not in a function timeout.

Scheduling & cron

Run a job in ten minutes or every night at 3am. Delayed and repeating jobs fire from our server even while your app is scaled to zero.

Rate limits

Cap calls to a third-party or AI API by time window — enforced on our server, so a traffic spike can't blow through your provider quota.

Concurrency

Decide how many jobs run at once per queue. The real BullMQ scheduler honors it across every invocation of your app.

Flows

Fan work into parent/child graphs with FlowProducer and gather child results — the dependencies are tracked for you.

Deduplication

Collapse duplicate jobs with a dedup key, so a double-submitted form or a retried request only runs the work once.

Built on real BullMQ

Drop-in compatible with the BullMQ API.

Real BullMQ runs your jobs, so the API you reach for is the API you already know.

new Queue() / queue.add()new Worker(name, processor)attempts + backoffdelay & priorityJob Schedulers (cron / every)rate limits & concurrencyFlowProducer graphsdeduplicationgetJob / getJobCountsupdateProgress / logretry / promote / changeDelaywaitUntilFinished()

A few methods that assume a worker running inside your own process work differently over a managed connection. See the compatibility guide.

Ship your first background job in minutes.

Create a project, grab your keys, and enqueue. No server, no Redis, no webhook plumbing — just the BullMQ you already know.