Vercel Daemons Put Long-Running Queue Workers on Vercel

Vercel opened a public beta of Daemons on Oct. 15, letting teams run always-on worker processes that pull jobs from queues and databases without exposing an HTTP server (Vercel changelog, Oct. 15, 2026).

What Shipped

Vercel’s changelog said a daemon is a long-running process that pulls and executes work from Vercel Queues, a database or a third-party system. It named three uses: consumers for Vercel Queues in poll mode, 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 need no inbound connections.

Per the post, setup is four steps. Package the app and its dependencies in a Dockerfile or Containerfile. Add a daemons entry to vercel.toml, vercel.ts or vercel.json at the project root. Set connection details as production environment variables. Deploy to production.

The entry takes four fields: root, the directory holding the worker code; entrypoint, the container build file; command, the startup command as an array; and instances, a count per region. Vercel’s example runs one Celery worker in iad1, its Washington, D.C. region.

Daemons run as containers on Fluid compute and deploy alongside the app in the same project. Vercel said it builds the image and keeps the configured number of instances running in each region. It restarts any that exit or crash. Output lands in the project’s runtime logs. CPU and memory metrics require Observability Plus.

The Take

Vercel Functions are built around a request: a function wakes up, answers and goes away. A queue consumer or a CI runner has no request to answer. It has to sit and wait for work.

Daemons close that gap. Vercel’s Python general availability post the same day pointed long-running workers to Daemons. Firerun has tracked the same direction since July, when Vercel Functions began running Dockerfile-based backends. The company wants the frontend, the API and the background workers in one project.

That is convenient for teams already deploying there. It also bets that people will accept an instance count in vercel.json in place of a managed worker service.

Key Takeaways

• Vercel Daemons entered public beta Oct. 15, 2026.
• Each daemon is a container on Fluid compute with no HTTP server, restarted automatically on exit or crash.
• Config is a daemons entry with root, entrypoint, command and per-region instances.