/daemons

name: daemons
description: Vercel Daemons guidance — long-running background workers built from a Dockerfile and declared under the `daemons` key in vercel.json. Use when running queue consumers, Celery/Sidekiq/BullMQ workers, workflow workers, or job runners next to an app on Vercel; configuring daemon instances per region, memory, or command; handling SIGTERM; or choosing between Daemons, Functions, Queues, and Workflows.
summary: "Vercel Daemons (public beta) run long-running containers with no inbound traffic, declared under the top-level `daemons` key in vercel.json as `{ root, entrypoint: 'Dockerfile', instances: { iad1: 2 } }`. Vercel builds the image, rolls it out with the production deployment, keeps the instance counts per region, and sends SIGTERM (10s grace) on rollout. Production only during the beta."
metadata:
  priority: 6
  docs:
    - "https://vercel.com/docs/daemons"
    - "https://vercel.com/docs/daemons/config-reference"
    - "https://vercel.com/docs/daemons/managing-daemons"
    - "https://vercel.com/docs/daemons/limits"
    - "https://vercel.com/docs/build-output-api/daemons"
  sitemap: "https://vercel.com/sitemap.xml"
  pathPatterns:
    - 'vercel.json'
  bashPatterns: []
  importPatterns: []
  promptSignals:
    phrases:
      - "vercel daemon"
      - "daemons key"
      - "daemon on vercel"
      - "daemons on vercel"
      - "worker on vercel"
      - "celery on vercel"
      - "sidekiq on vercel"
      - "bullmq on vercel"
    allOf:
      - [daemon, vercel]
      - [daemon, project]
      - [worker, vercel, long-running]
      - [worker, vercel, always-on]
      - [worker, vercel, background]
      - [consumer, vercel, long-running]
      - [celery, worker, vercel]
      - [sidekiq, vercel]
      - [bullmq, worker, vercel]
      - [runner, vercel, self-hosted]
    anyOf:
      - "daemon"
      - "worker"
      - "long-running"
      - "always-on"
      - "celery"
      - "sidekiq"
      - "bullmq"
      - "dockerfile"
      - "instances"
      - "sigterm"
    noneOf:
      - "systemd"
      - "docker daemon"
      - "dockerd"
      - "daemonset"
      - "launchd"
      - "web worker"
      - "service worker"
      - "cloudflare worker"
    minScore: 6
retrieval:
  aliases:
    - Vercel Daemons
    - daemon
    - background worker
    - long-running worker
    - queue consumer
  intents:
    - run a long-running background worker on Vercel
    - run a queue consumer next to my app
    - deploy a Celery, Sidekiq, or BullMQ worker
    - configure the daemons key in vercel.json
    - scale daemon instances per region
    - handle SIGTERM for graceful shutdown
    - choose between Daemons, Functions, Queues, and Workflows
  entities:
    - daemons
    - instances
    - entrypoint
    - root
    - resources.requests.memory
    - VERCEL_OIDC_TOKEN_FILE
    - PollingQueueClient
  examples:
    - add a BullMQ worker to my Next.js project on Vercel
    - run a Celery worker next to my FastAPI service
    - poll Vercel Queues from an always-on worker
    - my daemon does not run on preview deployments
    - how do I scale my daemon to two regions

Vercel Daemons

You are an expert in Vercel Daemons, the long-running background processes that run from a container image in the same project as an app.

Daemons are [in Public Beta on all plans](https://vercel.com/docs/daemons). Say so when you recommend them.

What It Is

A daemon is a named resource in a project that runs a fixed number of identical instances of one container image in each region you list. Vercel builds the image from the daemon's `Dockerfile` or `Containerfile`, rolls it out when the deployment becomes the production deployment, restarts instances that exit or crash, and forwards `stdout`/`stderr` to the project's Logs. Daemons run on Fluid compute.

Daemons **cannot receive inbound traffic**. They pull work from a queue, a workflow engine, or an external API.

When to Use Daemons

Use a daemon when the process owns a continuous loop that retrieves work.

| Need | Use | Why | |------|-----|-----| | Always-on queue consumer (Vercel Queues poll mode, SQS, Kafka, Redis), Celery/Sidekiq/BullMQ worker, workflow-engine worker, self-hosted CI runner | **Daemons** | Long-running loop, fixed instances per region, no request needed | | HTTP APIs, webhooks, streaming, WebSockets | Vercel Functions (`⤳ skill: vercel-functions`) | Daemons can't receive traffic | | Fire-and-forget background job, fan-out, buffering with Vercel invoking your handler | Vercel Queues push mode (`⤳ skill: queues`) | Serverless, scales automatically, works in previews | | Durable multi-step logic with sleep, hooks, or approvals | Vercel Workflows (`⤳ skill: workflow`) | Durable steps and replay | | Run code on a schedule | Cron Jobs (`⤳ skill: vercel-functions`) | Time-based trigger | | Run untrusted or AI-generated code in isolation | Vercel Sandbox (`⤳ skill: vercel-sandbox`) | Ephemeral microVMs | | Multiple frontends and backends in one project | Vercel Services (`⤳ skill: vercel-services`) | Daemons sit next to services; they are not services |

If the user's work is request-driven, prefer Functions or Queues push mode. Reach for a daemon only when something must stay running.

Quick Start

Add a `Dockerfile` in the worker's source directory:

# worker/Dockerfile
FROM node:24-slim
WORKDIR /app
COPY package.json package-lock.json ./
RUN npm ci --omit=dev
COPY . .
CMD ["node", "worker.js"]

Declare the daemon under the top-level `daemons` key:

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

The same configuration works in `vercel.toml` as a `[daemons.worker]` table. Deploy to production. Vercel builds the image, pushes it to Vercel Container Registry as `daemon.worker`, and starts two instances in `iad1`.

Daemons are always d