Vercel Daemons Public Beta: Run Background Processes Without an HTTP Server

Vercel is evolving from a pure web app hosting platform into a more general-purpose compute platform. The newly launched public beta of Vercel Daemons lets developers run long-running background processes on Vercel without having to wrap every task in an HTTP server.

What Are Vercel Daemons

Daemons let you run long-lived processes on Vercel that actively pull and execute tasks from Vercel Queues, databases, or third-party systems. Unlike traditional serverless functions, Daemons don't rely on inbound HTTP requests to trigger them—they run continuously as always-on containers.

Typical use cases for this pattern include: clients consuming Vercel Queues in polling mode, consumers for Celery, BullMQ, RabbitMQ, or Kafka; long-polling workers for Temporal or Cadence; and self-hosted CI runners for GitHub Actions, GitLab, or CircleCI—these runners can actively poll for jobs rather than accepting external connections.

Serverless functions have long been Vercel's core execution model: function instances are triggered by HTTP requests or other events, and once they finish handling a given invocation they are frozen or reclaimed, so each execution has a timeout limit (typically tens of seconds to a few minutes on the free and Pro plans). This model suits request-response workloads but not scenarios that require continuously listening to a queue, maintaining long-lived connections, or polling remote jobs. A daemon, by contrast, is the traditional Unix concept of a persistent background process that lives on after startup, loops through tasks, and doesn't depend on any single user request. Vercel Daemons brings this semantics to a managed platform: you declare the number of instances and regions, the platform spins up the containers and keeps them alive, and the process itself decides when to pull the next message from the queue. The key to understanding the difference is the trigger—serverless is driven by external events, while a daemon is actively driven by a loop inside the process.

Under the Hood: Containers on Fluid compute

Daemons run on top of Fluid compute, deployed as containers, and live in the same project as your application. Vercel handles building the image and maintaining it according to the number of instances you configure in each region. If an instance exits or crashes, the platform automatically restarts it.

This design is consistent with Vercel's long-standing "deploy as infrastructure" philosophy. You don't need to manage a separate worker cluster, nor set up a separate deployment pipeline for background tasks—Daemons and the app share the same project context, and logs and metrics are unified in the Vercel console.

Fluid compute is a compute model Vercel introduced earlier that adds instance reuse and concurrent processing on top of traditional serverless, allowing the same runtime environment to serve multiple concurrent requests, thereby reducing cold-start frequency and idle resources. It remains fundamentally an on-demand, auto-scaling managed runtime—it just relaxes the granularity from "one instance per request" to "one instance handling multiple tasks." Daemons are built on the same runtime but bypass the on-demand triggering logic: instances are kept running continuously and don't enter an idle-reclamation state. This means Daemons' resource billing is closer to always-on containers—based on instance count and runtime rather than invocation count. For developers, this brings the feasibility of long-running tasks while also requiring a more careful balance between instance count and cost.

Configuration: One Dockerfile Plus a Config Block

The getting-started flow is fairly straightforward. Developers need to package the application and its dependencies into a Dockerfile or Containerfile, then add a daemons entry to the configuration file in the project root.

The official example runs a Celery worker in worker/Dockerfile, deployed to the iad1 (Washington, D.C.) region:

#:schema https://openapi.vercel.sh/vercel.json
[daemons.celery]
root = "worker/"
entrypoint = "Dockerfile"
command = ["celery", "-A", "app", "worker", "--loglevel=info"]
replicas.iad1 = 1

The connection information the worker needs is injected via the project's production environment variables, after which you simply deploy to production. Vercel starts the configured instances, output appears in the project's Logs, and CPU and memory metrics can be viewed through Observability Plus.

Celery is the most widely used distributed task queue framework in the Python ecosystem, typically consisting of one or more worker processes that connect to a message broker (such as Redis or RabbitMQ), pull tasks from the queue, and execute them. Similar solutions include BullMQ (Redis-based) in the Node.js ecosystem, Python's RQ, and cross-language Kafka consumer groups and Temporal workflow workers. What these all have in common is that the worker must run as a persistent process and actively pull tasks rather than passively waiting for HTTP requests. Because of this, they were previously difficult to deploy directly on pure serverless platforms and often required a separate container hosting service. The fact that the Daemons configuration example runs a Celery worker directly shows that Vercel can now host this kind of standard background processing process.

What It Means for the Platform and Developers

Daemons fills an obvious gap in Vercel's background task handling. Previously, running a queue consumer or long-polling worker on Vercel usually required external services or accepting some degree of architectural compromise.

For teams already using Vercel, this means some workloads that previously needed to be migrated to other platforms can now stay in the same project. Especially for teams already using mainstream queue solutions like Celery, BullMQ, and Kafka, the migration cost is mainly adapting to containerization and configuration files, without needing to rewrite task logic.

On the other hand, Daemons also brings Vercel closer to platforms known for container orchestration. Whether it's suitable for hosting the background processing of core business still depends on specific reliability requirements and cost considerations, but as a public beta feature, it has already added a previously missing piece to Vercel's runtime landscape.

For more details, see the official Vercel Daemons documentation.

Self-hosted CI runners refer to continuous integration executors that teams run on their own infrastructure rather than using the managed runners provided by GitHub, GitLab, or CircleCI. Typical implementations (such as GitHub Actions self-hosted runners) use a "polling" model: the runner actively requests pending jobs from the platform, executes them, and then pulls the next one—the entire process requires no inbound connection from the platform to the runner. This outbound-connection model is well-suited for deployment in network environments that cannot expose public ports or that want to control compute costs and data boundaries. Vercel Daemons supporting this scenario means teams can put CI executors and business applications under the same project and billing system, avoiding the need to maintain a separate set of container orchestration infrastructure.

One-line Summary

Vercel Daemons is now in public beta, allowing long-running background processes on Vercel and filling a gap in its serverless platform.

Paragraph Summary

Vercel Daemons has entered public beta, letting developers run long-lived background processes on Vercel without wrapping every task in an HTTP server. Daemons run as containers on Fluid compute, live in the same project as the owning application, can actively pull tasks from Vercel Queues, databases, or third-party systems, and are automatically restarted by the platform if an instance crashes. Typical use cases include consumers for Celery, BullMQ, RabbitMQ, and Kafka, long-polling workers for Temporal, and self-hosted CI runners. Deployment involves packaging a Dockerfile in the project and adding a daemons entry to the root config file specifying root, entrypoint, command, and per-region replica counts, with connection info injected via production environment variables. Daemons fills Vercel's gap in background task handling, letting workloads that previously needed migration to other platforms stay in the same project, though whether to host core business still depends on reliability requirements and cost.