Vercel Daemons is now in public beta
By Steven Van ·
Daemons run container-based background workers on Fluid compute on every plan, but only in production and without autoscaling during the beta.
Vercel Daemons is in public beta on all plans, including Hobby, within each plan's quotas. A daemon runs a long-lived process from a container image in the same project as an app, without needing an HTTP server. Daemons cannot receive inbound network traffic. They pull work from a queue, a workflow engine or an external API.
What daemons are for
The release note lists three kinds of workload:
- Consumers using Vercel Queues poll mode, Celery, BullMQ, RabbitMQ or Kafka.
- Temporal or Cadence workers that long-poll their task queues.
- Self-hosted CI runners for GitHub Actions, GitLab or CircleCI that poll for jobs without inbound connections.
How it works
Daemons run containers on Fluid compute. Vercel builds the Dockerfile or Containerfile for each daemon and pushes the image to Vercel Container Registry. When a deployment becomes the production deployment, including after a promotion or rollback, Vercel rolls out the configured daemons in each region and gracefully terminates instances from the previous deployment. It maintains the instance count set for each region and restarts instances that exit or crash. Output from stdout and stderr appears in the project's Logs.
Setup
Package the application and its dependencies in a Dockerfile or Containerfile, then add a daemons entry to the configuration file at the project root. The file can be vercel.json or vercel.toml. The release note's example uses worker/Dockerfile to run one Celery worker in iad1 (Washington, D.C.), with a command field that replaces the image's ENTRYPOINT and CMD. Connection details go in the project's production environment variables, and then the project is deployed to production.
Daemons are declared at the top level of the configuration, not inside a service, so they can sit beside an app that uses Services. Each instance gets the deployment's environment variables and an OIDC token. Instance counts can be overridden without a new deployment, and overrides persist across deployments until cleared.
Shutdown and local use
Vercel sends SIGTERM when it stops an instance, for example during a rollout, a manual restart, a reduced instance count or a removed daemon. By default it waits 10 seconds before terminating the process. The documentation advises making jobs idempotent, since an instance can stop at any time. vercel dev does not run daemons yet, so they need to be run locally with Docker.
Beta limits
Daemons run only in production. During the beta they do not support preview deployments, autoscaling, persistent storage, or projects with a root directory in a subfolder. CPU and memory metrics require Observability Plus.
Details are in the Daemons documentation, and Vercel lists it as a public beta.