By Vercel just shipped what developers have been routing around for years. At Ship 2026 in San Francisco on October 15, the company announced Daemons — always-on background workers that run as containers on its Fluid compute platform. Queue consumers, Temporal workers, self-hosted CI runners. Deploy a Dockerfile, set instance counts per region, and Vercel keeps them alive and restarts them on crash. It is in public beta on all plans today.
The Problem: Serverless Functions Die
Vercel built its reputation on serverless functions that execute and terminate. That model is excellent for API routes and server-side rendering. It is useless for background work that needs to stay alive — queue consumers polling Redis or Kafka, Temporal task-queue workers waiting for jobs, Celery pipelines processing video or images.
Teams solved this by splitting their stack: Vercel for the frontend, Railway or Render or a bare EC2 instance for the workers. That works, but it adds a second platform, a second deployment pipeline, and a second invoice. Daemons offers a path to consolidation for teams already invested in the Vercel ecosystem.
How Vercel Daemons Work
A Daemon is a container. You write a Dockerfile, add a daemons block to your vercel.toml, and Vercel runs the configured number of replicas per region. If the process exits or crashes, Vercel restarts it automatically. There is no HTTP server involved — Daemons are pull-based by design. Your worker fetches work from an external queue or database rather than receiving inbound requests.
The configuration is minimal. The full documentation is at vercel.com/docs/daemons.
[daemons.worker]
root = "worker/"
entrypoint = "Dockerfile"
replicas = { iad1 = 2 }A Celery worker looks nearly the same with an explicit command override:
[daemons.celery]
root = "worker/"
entrypoint = "Dockerfile"
command = ["celery", "-A", "app", "worker", "--loglevel=info"]
instances.iad1 = 1What You Can Run Today
Vercel explicitly supports these workload patterns in the beta:
- Queue consumers: Celery, BullMQ, Dramatiq, RabbitMQ, Kafka
- Temporal and Cadence workers: long-poll task queues without inbound connections
- Self-hosted CI runners: GitHub Actions, GitLab, CircleCI runners that poll for jobs
- CPU-bound pipelines: video transcoding with FFmpeg, image processing
- Database job processors: pull pending rows from Postgres, process, mark done
HTTP servers are not the intended model here. If your “daemon” listens on a port for requests, use Vercel Functions or containers instead. Daemons are for work that pulls rather than receives.
The Beta Limits: Know Before You Deploy
Hobby plan: 10 vCPU-hours per month. One single-vCPU daemon exhausts that quota in about ten hours of runtime. Vercel stops your workers when you hit the limit and logs an error. They resume at the start of next month, or when you upgrade to Pro.
Pro plan: up to 16 concurrent vCPUs and 32 GiB of memory. That is enough for real production workloads. There is no autoscaling during the beta — you set a fixed instance count and provision for peak load.
The honest take: Hobby is for trying Daemons. If you need workers running continuously all month, Pro is the minimum viable plan. Vercel is being transparent about this distinction rather than hiding it in fine print.
The Wider Picture: Vercel Is Building a Backend Story
Daemons did not ship alone. At Ship 2026, Python hit general availability on Vercel — FastAPI, Flask, and Django with standard CPython, PyPI, and uv support. The company reports 150,000 teams already deploy Python backends on the platform. Vercel Drives, persistent storage for AI agent sandboxes, also reached general availability: files survive across sandbox sessions, drives can be forked for parallel agents, and each drive supports up to 16 TiB.
The full Ship 2026 announcement covers all of this in detail: Backends on Vercel: Python, containers, and Daemons. The pattern is clear — Vercel is extending from frontend-first to full-stack hosting, and Daemons is a meaningful piece of that move.
Who Should Evaluate This Now
If you already deploy on Vercel and run pull-based workers on Railway or Render for a simple queue consumer or CI runner, this is worth evaluating today. The consolidation value — one platform, one deployment system, one bill — is real if your worker workloads are straightforward.
If your workers need autoscaling, stateful long-lived connections, or complex networking, Railway and Fly.io remain better fits for now. Daemons is a solid v1 that covers the common case. The edge cases come later.
