Vercel Daemons: background workers with fixed instances

Vercel Daemons, in public beta since October 15, 2026, keep a worker running continuously on Fluid compute, but they do not autoscale: you set a fixed instance count per region. Vercel's own pages also disagree on how long a daemon gets to shut down after SIGTERM. Here is what to check before moving a queue worker onto it.

• Status: public beta, announced October 15, 2026. Everything below is as of October 20, 2026.
• Availability: all plans, including Hobby, within each plan's quotas.
• Scaling: a fixed number of instances in each region, with no autoscaling.
• Price: not stated on any Daemons page we read. More on that below.

We have not run Vercel Daemons in production. This post is a close reading of Vercel's announcement, documentation and knowledge-base pages, with our own reasoning labelled as ours. Where a claim comes from one page only, we say so.

Vercel Daemons run a container you already have, not new code

The launch post describes Vercel Daemons as a way to deploy containers as continuously running background workers on Fluid compute. You choose the number of instances in each region, and Vercel maintains that capacity by restarting processes when they exit or crash.

The changelog lists the workloads it has in mind: consumers using Vercel Queues 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. What they share is that the process reaches out for work. Nothing sends it an HTTP request.

You package the worker in a Dockerfile or Containerfile and add a daemons entry to one configuration file at the project root. This is the changelog's Celery example in vercel.toml:

[daemons.celery]
root = "worker/"
entrypoint = "Dockerfile"
command = ["celery", "-A", "app", "worker", "--loglevel=info"]
instances.iad1 = 1

The configuration reference adds two details. A command replaces the image's ENTRYPOINT and CMD, and Vercel does not run it through a shell, so shell expansion needs an explicit sh -c. Memory is set per instance at 1, 2, 4 or 8 GiB, with 1, 1, 2 and 4 vCPUs respectively and a 2 GiB default.

The deployment model is the part that suits teams already on Next.js. The launch post's example defines a Next.js frontend as a service and adds a video processor as a daemon in the same file, so the worker ships in the same project as the app. Vercel builds the image on deploy, and instance output appears in the project's Logs.

Fixed instance counts are the biggest change from serverless

The managing page is blunt: each daemon runs a fixed number of instances in each region, and Vercel does not currently autoscale daemons. The limits page lists autoscaling among the unsupported beta features and says scaling from the CLI and API is coming soon.

In practice you are choosing capacity the way you would for a small pool of workers on your own machines. The ceiling is 100 instances per region per daemon. How many you need is your call, and so is noticing when the queue backs up. In our view that makes queue depth and message age the first things to alert on, because nothing in the platform will add a worker for you. That is our reasoning, not a Vercel statement.

One trap is worth knowing. You can override instance counts from the dashboard without deploying, and the managing page says those overrides stay in place across deployments. While an override is set, changes to instances in vercel.json do not take effect. Someone who scales up by hand during an incident can leave a setting that quietly beats the file in the repository until they choose Clear scaling overrides.

Team quotas also apply. On Pro the default quota is 16 vCPUs and 32 GiB of memory running at once, across all of the team's projects. At the default 2 GiB and 1 vCPU size, both limits work out to 16 instances for the whole team. That is our arithmetic from the stated figures. Enterprise quotas are custom.

Vercel's own pages disagree on the shutdown window

When Vercel replaces an instance during a rollout, a manual restart or a scale-down, it sends SIGTERM and later terminates the process. The main docs page, the configuration reference and the limits page all give the default wait as 30 seconds, adjustable from 0 to 3,600 with terminationGracePeriodSeconds.

Two knowledge-base guides say something different. The guide to choosing between Functions, containers and Daemons says Vercel gives an instance 10 seconds to shut down, and The Complete Guide to Vercel Daemons says it allows 10 seconds by default. We cannot tell from outside which is current. If your job needs more than a few seconds to finish a unit of work, set terminationGracePeriodSeconds explicitly and stop relying on either default.

The docs are also clear about what a stop means for your code. An instance can stop at any time, so jobs need to be idempotent and interrupted jobs safe to retry. For queue consumers, acknowledge a message only after you finish processing it. During a rollout, old and new versions run side by side for a short time, so both must be able to consume from the same queue and your database migrations must stay compatible with the previous version.

Functions, containers and Daemons answer different questions

Vercel's comparison guide frames the choice by what starts the work, and summarises it as "Container images change what a Function runs; Daemons change how a worker runs." The table below restates its comparison.

Property	Functions from source	Functions from container image	Daemons
Work starts when	A request arrives	A request arrives	The worker receives or pulls work
Receives inbound HTTP	Yes	Yes	No
Capacity	Scales automatically	Scales automatically	Fixed instances per region
Work lifecycle	Bounded invocation	Bounded invocation	Continuous process
You maintain	Application code	Application code and Docker image	Worker code, Docker image and instance counts

Vercel Queues sits between these. The same guide says that for a Stripe webhook you should handle the request in a Function and, if fulfilment needs independent retries, publish the follow-up work to Vercel Queues and use a push consumer, which processes the message without a polling worker. The Daemons docs say Queues offers serverless message processing with preview deployment support, and that Daemons can consume Queues in poll mode.

The guide also warns against a tempting shortcut. Functions that run from container images scale down when idle, so packaging a polling worker as one does not keep it running. And waitUntil() or Next.js after() share the function's duration limit, so unfinished tasks are cancelled if the function times out.

If you are weighing this against the managed-function route on AWS, our earlier pieces on the AWS Lambda 90 minute timeout and on how Lambda web functions change billing and concurrency are related reading on running background work on AWS.

The beta leaves out features a production worker may need

The limits page lists what Daemons do not support during the beta. Check this list against your worker before anything else:

• Preview deployments. Daemons run only in production. Vercel's suggested alternative is to test by running the image locally with Docker.
• Inbound HTTP or TCP. A daemon cannot be the target of a rewrite or a service binding.
• Persistent local storage. State belongs in Vercel Blob or a database.
• vercel dev. It prints a warning and starts the rest of your project without the daemon.
• Subfolder root directories. Projects with a root directory such as apps/web cannot add daemons yet. This one matters for monorepos.

The Hobby plan has a hard edge as well. Its quota is 10 Active CPU-hours a month per team, and when a team reaches it, Vercel stops all of the team's daemon instances and logs an error. They start again at the beginning of the next month or on upgrade to Pro. Observability is also gated: the changelog says CPU and memory metrics are available with Observability Plus.

What Vercel Daemons will cost is not stated on the pages we read

The announcement pages describe quotas, not prices. The launch post says containers deployed as Functions use Active CPU pricing, which does not charge for idle time spent waiting on API responses, database queries or LLM inference. The Daemons docs say the Hobby quota counts Active CPU, so long-polling an empty queue does not count, though HTTPS requests still use some CPU for encryption and signing.

That is not a published rate for Pro or Enterprise. Vercel's Functions pricing page sets out Active CPU and Provisioned Memory charges for Functions, and it does not mention Daemons at all. We do not know whether a continuously running instance is billed for provisioned memory while it waits, and we will not guess. Ask Vercel, or run one small daemon on a Pro team and read the usage breakdown, before you put a cost on a migration.

When Vercel Daemons are the wrong choice

Several common workloads do not fit, and Vercel's own guide says so for most of them.

• Bursty traffic that needs workers to scale itself. With a fixed count you size for the peak or accept a backlog. The guide's answer to a month-end report spike is Vercel Queues buffering requests for a consumer Function, with Workflows when you need retries across steps.
• Approvals and long waits. The guide sends a flow that waits days for a reviewer to Vercel Workflows, which can resume after crashes or deployments.
• A nightly import. The guide sends it to Cron Jobs, and says to choose a Daemon only when the integration needs continuous polling.
• Anything that must be tested per pull request. No preview support means your staging story is a local Docker run.
• A worker that already runs well elsewhere. If a Celery pool on your existing AWS setup is stable and monitored, the saving is one deployment pipeline. A public beta with no autoscaling is a fair price to refuse for that. This one is our judgement.

What we would do before moving a worker

Our work centres on Next.js, Node, AWS, Docker and serverless, so the question we would put to a client is not whether Daemons are good, but whether the worker is the kind of thing a beta should hold. A queue consumer that is idempotent, has a known peak and tolerates a restart is a reasonable pilot. One with unbounded bursts, large local state or per-branch testing is not.

For a pilot, pick one low-risk consumer. Set terminationGracePeriodSeconds yourself, alert on queue age, record the usage numbers for a week, and write down who clears the scaling override. If the app side of this is your next step, our web app development team builds the Next.js side, and our serverless architecture and DevOps and cloud engineering practices cover the worker and the cloud around it. If the worker is a long-running agent rather than a queue consumer, our note on where long-running agents live in Docker Cloud Sandboxes looks at a different tool for that job.

Your next decision is a small one: choose the single worker you would move first, and check it against the five unsupported features above. If it passes, you have a pilot. If it fails on any of them, you have your answer for now.