Vercel Daemons is now in public beta

Vercel Daemons gives Vercel projects a place to run background workers that go looking for work instead of waiting to be called. A typical web deployment answers incoming HTTP requests; a daemon has no HTTP server at all. It keeps running and pulls jobs from Vercel Queues, a database or an outside system. The announcement's examples are queue consumers built on Celery, BullMQ, RabbitMQ or Kafka, Temporal or Cadence workers that long-poll their task queues, and self-hosted CI runners for GitHub Actions, GitLab or CircleCI, which poll for jobs and so need no inbound connections (vercel.com).

Daemons are containers. A developer packages the worker and its dependencies in a Dockerfile or Containerfile and adds a daemons entry to the project's configuration file, naming the build directory, the command to run and how many instances to keep in each region; the changelog's example runs one Celery worker in iad1, Washington, D.C. Vercel builds the image, runs it on Fluid compute in the same project as the app, holds the configured instance count and restarts any instance that exits or crashes. Output appears in the project's logs, while CPU and memory metrics require Observability Plus.

The feature is in public beta, and the changelog does not give pricing or limits. It arrived alongside the general availability of Python on Vercel, where Vercel points to Daemons as the way to run long-lived Python workers together with their packages and system dependencies.