Run background workers on Vercel

{
  "$schema": "https://openapi.vercel.sh/vercel.json",
  "daemons": {
    "worker": {
      "root": "worker/",
      "entrypoint": "Dockerfile",
      "instances": { "iad1": 2 }
    }
  }
}

import { send } from '@vercel/queue';
 
export async function POST(request: Request) {
  const upload = await request.json();
 
  // Return now. A consumer processes the upload later.
  const { messageId } = await send('uploads', upload);
 
  return Response.json({ messageId });
}

import { sleep } from 'workflow';
 
export async function fulfillOrder(orderId: string) {
  'use workflow';
 
  await chargePayment(orderId);
 
  await sleep('3 days');
  await sendFollowUp(orderId);
}

Vercel Daemons run workers such as Celery, BullMQ, and Sidekiq alongside your application. Functions, Cron Jobs, Queues, Workflows, and Sandbox support other ways to start and execute background work.

Each example above needs more setup to run. The daemon needs a Dockerfile in worker/, the queue needs a consumer for the uploads topic, and the workflow needs the step functions it calls. See Get started for the full setup.

Choose based on what starts the job, whether it needs a continuously running process, and how it should recover from interruptions.

These services work together. A cron job can start a workflow, a Function can publish to a queue, and a daemon can consume queued work and run code in a sandbox.

Use Vercel Daemons for a process that stays running and pulls work from a queue, workflow engine, or external API. Package your worker and its dependencies in a container using a Dockerfile, then configure its regions and instance counts in your project.

Daemons support workers for Celery, BullMQ, and Sidekiq, as well as custom consumers for Vercel Queues, Amazon SQS, Kafka, or Redis. You can keep your worker framework and connect it to its existing broker. Vercel manages the worker process; your broker or queue manages job delivery.

Vercel restarts daemon instances that exit or crash and forwards their output to runtime logs. During deployments and shutdowns, handle SIGTERM so your worker can finish or release its current job. Store durable state in your queue, a database, or object storage so another instance can resume the work.

During the beta, daemons run in production with manually configured instance counts and ephemeral local storage. Review Daemons limits for supported configurations, quotas, and deployment restrictions, then follow the Daemons quickstart.

Deploy a worker alongside the frontend or backend that creates its jobs. For example, a video application can use this flow:

1. The browser uploads a video directly to Blob, then a Function publishes a job containing the file's location.
2. A daemon retrieves the job, processes the video with ffmpeg, and stores the output in Vercel Blob.
3. The worker updates the job's status in a database so the frontend can display the result.

Use Services when your project contains multiple applications, such as a Next.js frontend and a Python API. See Attach daemons to an existing app for project configuration.

For jobs with several steps or long waits, use Workflows to persist progress between steps. For queue consumers, make repeated delivery safe: use an idempotency key or a stored job result to avoid repeating an external action. See Queues delivery semantics and Workflow concepts.

Yes. Vercel supports continuous workers with Daemons, event-driven jobs with Queues, scheduled jobs with Cron Jobs, and durable multi-step tasks with Workflows. For a short task that continues after an HTTP response, use waitUntil in a Function or after() in Next.js.

Yes. Vercel Daemons keep your configured worker instances running and restart them if they exit or crash. Daemons pull work through outbound connections. Use Functions or Services for inbound application requests. Instances can restart during deployments, so persist job state outside the process and handle shutdown gracefully.

Yes. Package your Celery, BullMQ, or Sidekiq worker in a container and deploy it as a daemon. Connect it to the broker your framework requires, such as Redis or RabbitMQ. The background workers guide includes worker examples and links to migration guides.

It depends on how you run it. Work in a Function, including waitUntil, shares the function's maximum duration. Daemons run continuously instead of using a per-request invocation, subject to their quotas and lifecycle. Workflows can persist progress across invocations and wait for external events. Design long jobs to recover from interruptions.

You can use both. Queues stores and delivers messages; a daemon can poll Queues and process them. Use Queues push delivery when a Function can handle each job within its duration limit. Use a daemon when you need a continuous consumer, a worker framework, or dependencies packaged in a container. See Queues poll mode.

Use after() for work that runs after a response and fits within the function's duration. For work that needs retries or must survive an interrupted request, publish a queue message or start a workflow. Use a daemon for a separate, continuously running worker alongside your Next.js application.

Yes. Cron Jobs call an endpoint in your production deployment on a schedule. That endpoint can perform a task within the function's duration, enqueue work, or start a workflow. Use a workflow when the job needs multiple steps or must wait before continuing.

Yes. Use Workflows for agents that preserve progress and resume after interruptions or human input. Use a daemon to poll for work or process jobs for a hosted agent, and Sandbox for isolated code execution. See Use Vercel Daemons with eve agents for examples that combine workers and durable agent sessions.

• Deploy a daemon for a continuous background worker.
• Publish and process a queue message for event-driven jobs.
• Create a workflow for durable multi-step work.
• Configure a cron job for recurring tasks.
• Follow the background workers guide for detailed examples, failure handling, and migrations from other platforms.