What’s actually slowing this PC down?
Pick the symptom - the matching free tool is one click away.
iTechGuides is reader-supported. When you buy through links on our site, we may earn an affiliate commission. As an Amazon Associate I earn from qualifying purchases. Learn more
Vercel introduced Daemons in public beta on October 15, 2026, adding a way to keep containerized backend workers running continuously. You choose how many instances should run in each region; Vercel keeps those processes alive and restarts them if they exit or crash.
Daemons are designed for pull-based work: a process polls a queue or database, takes jobs as they appear, and continues processing without waiting for an incoming HTTP request. That makes them a new option for queue consumers, controlled-concurrency orchestration, and CPU-heavy jobs such as video transcoding.
What Vercel Daemons do
A Daemon is a long-running container deployed as part of a Vercel project. Instead of starting only when a request arrives, it starts, announces that it is ready, and repeatedly reaches out for work. Vercel maintains the configured instance count in each selected region and restarts a process after an exit or crash.
Vercel CTO Malte Ubl described the design as “almost the opposite of temporary.” The launch model supports pull-based workloads, so the worker must know how to poll or consume from the queue or database you connect to it. The public-beta announcement does not describe Daemons as a general-purpose trigger for arbitrary inbound requests.
#1 Best Overall
Workloads that fit
- Queue consumers: workers that continuously fetch jobs and acknowledge them after successful processing.
- Build and deployment orchestration: controlled worker capacity can prevent unbounded concurrency when external systems impose rate limits, such as GitHub APIs.
- CPU-heavy media processing: video, audio, image, or document jobs that are inefficient to squeeze into short request handlers.
- Other continuously running backend processes: services that need to maintain a polling loop rather than wait for HTTP traffic.
Why this is different from Vercel’s request-oriented compute
Vercel’s traditional server-side model is request-driven. Functions and Vercel Services backends run as Vercel Functions on Fluid compute by default. Fluid lets instances handle concurrent requests, scale automatically, and reuse resources, which is especially useful when work spends much of its time waiting on databases, external APIs, or model calls.
Vercel introduced Fluid compute on February 4, 2025 as a serverless model with server-like flexibility. Its documented characteristics include scaling from zero to peak demand, pre-warmed instances, streaming, post-response processing, and billing based on actual compute usage. Vercel reported cost reductions of up to 85% among early Fluid adopters, but that figure is an early-adopter report rather than a guarantee for every workload.
| Model | How work starts | Typical scaling behavior | Best fit |
|---|---|---|---|
| Daemons | Process starts and pulls work from a queue or database | Configured running instances per region; Vercel restarts failed processes | Continuous consumers, controlled concurrency, CPU-heavy background jobs |
| Functions | Incoming request or platform invocation | Request-driven scaling on Fluid compute | Stateless HTTP endpoints and short-lived handlers |
| Vercel Services | Service endpoint receives a request | Functions on Fluid compute by default, with concurrent request handling | Backend APIs and I/O-bound services |
| Long-lived process host | Process runs independently and pulls or receives work | Provider-specific instance and autoscaling controls | Workers that need capabilities or limits outside Vercel’s beta |
The distinction is workload shape, not simply whether code is written in a particular language. A Python API that waits on a database may fit Fluid compute; a Python process that spends hours polling a queue and running FFmpeg is a Daemon candidate.
Free tools Windows power users keep installed
One-click scans. No signup required.
Queue consumers and video processing on Vercel
Yes. The launch example uses a Next.js frontend, a Python API, and a containerized FFmpeg worker. The FFmpeg process pulls jobs from Vercel Queues, creates playback files and thumbnails, and runs independently of the web request that submitted the job.
A practical architecture
- Accept the job through an HTTP service. The frontend or API validates the request and records the job.
- Publish a queue message. Include an identifier for the source asset and the output requirements rather than keeping the HTTP request open.
- Let the Daemon claim work. Each running instance polls for available messages and applies your retry, visibility-timeout, and idempotency rules.
- Run the CPU-heavy operation in the container. For video, this can include transcoding and thumbnail generation with FFmpeg.
- Persist results and acknowledge the job. Store output metadata where the API can read it, then mark the queue message complete only after outputs are durable.
The exact queue settings, regional availability, resource limits, and failure semantics are not specified in the public-beta launch coverage, so production designs should confirm them in Vercel’s current documentation.
Concurrency is the central reason to use a Daemon
Request-driven scaling can create a new unit of work for every incoming event. That is useful for bursty APIs, but it can overwhelm a dependency that limits concurrent requests. Ubl cited Vercel’s own deployment pipeline as an example: deployment volume and GitHub rate limits make deliberately controlled concurrency preferable to unbounded parallel requests.
With Daemons, the number of active consumers is an explicit capacity decision. Increasing the instance count can raise throughput; keeping it low can protect a downstream API or database. Your worker still needs its own safeguards, including bounded parallelism inside each container, retries with backoff, idempotent job handling, and a way to move permanently failing messages aside.
What the documented pricing does—and does not—tell you
Vercel’s published Active CPU pricing applies to Fluid compute, not to a stated Daemons price. The June 25, 2025 changelog lists $0.128 per active CPU hour, $0.0106 per gigabyte-hour of provisioned memory, and an invocation charge. Vercel’s example puts a Standard instance running at 100% active CPU at about $0.149 per hour.
| Figure | Qualification |
|---|---|
| Up to 85% lower cost | Vercel’s 2025 report for early Fluid-compute adopters; not a universal savings rate |
| $0.128 per active CPU hour | Vercel Active CPU price listed June 25, 2025 |
| $0.0106 per GB-hour | Provisioned-memory price in the same Active CPU pricing documentation |
| About $0.149 per hour | Vercel example for a Standard instance at 100% active CPU |
The October 2026 launch report did not publish Daemons-specific pricing, hard quotas, supported regions, or a general-availability date. A continuously running process can also consume capacity while idle, so do not estimate a Daemon’s cost from Fluid’s per-invocation model. Check the current Daemons documentation and account-specific limits before committing a production workload.
Independent reader supportYour contribution helps us test, update, and keep practical guides available for everyone.Should an existing worker move from Render, Fly.io, Railway, or another host?
There is no automatic reason to move a stable worker. Daemons become attractive when keeping the worker beside your Vercel frontend and APIs reduces operational boundaries, or when private service integration and a single deployment workflow matter more than the maturity of a dedicated process host.
Choose Daemons when
- Your process is naturally a pull consumer and can run from a container.
- You want an explicit instance count by region and automatic restart after failure.
- The workload is CPU-heavy or needs deliberate concurrency rather than one handler per request.
- The rest of the application already lives on Vercel and the beta’s limits meet your requirements.
Keep the worker on a long-lived-process provider when
- You require a published production SLA, mature autoscaling controls, or capabilities not documented for the beta.
- Your worker depends on specialized networking, storage, hardware, or region support that Vercel has not confirmed.
- You already have reliable deployment, monitoring, and queue operations elsewhere and moving would add risk without a clear benefit.
Use a hybrid layout when
Many applications can leave the web-facing frontend and stateless APIs on Vercel while running the continuous consumer on Daemons or another process host. This separates request latency from background capacity, but it also means you must operate cross-platform authentication, secrets, observability, and failure handling.
What to verify before production
- Daemon pricing, billing treatment for idle time, and any minimum or maximum instance counts.
- Supported regions and whether the configured count is maintained independently in every region.
- Container CPU, memory, disk, networking, execution-time, and restart limits.
- Queue integration details: acknowledgement, visibility timeout, retry behavior, and duplicate delivery.
- Logs, metrics, alerting, graceful shutdown, and deployment behavior while jobs are running.
- Beta terms and the path to general availability.
Vercel reported that its container support had reached 5,000 teams and 150,000 container deployments by the 2026 launch coverage, while its control-plane API handled about one billion requests per month. Those figures indicate substantial platform activity, but they do not establish Daemons’ final reliability guarantees.
Bottom line for backend teams
Daemons fill the gap between Vercel’s request-triggered Functions and the always-running workers that sophisticated backends often need. Use them for containerized processes that continuously pull jobs, especially queue consumers and CPU-intensive media pipelines. Keep stateless, I/O-bound HTTP work on Functions or Services using Fluid compute. For a mixed application, a Vercel web tier plus a dedicated Daemon or long-lived worker is a sensible architecture—provided you validate the public beta’s pricing, quotas, regions, and operational behavior first.
Quick Recap
Product prices and availability are accurate as of the date/time indicated and are subject to change. Any price and availability information displayed on Amazon at the time of purchase will apply.
