Backends on Vercel: Python, containers, and Daemons
By Steven Van ·
Daemons run queue consumers and workflow workers beside an app on every plan, with Python now generally available and container support extended.
Vercel Daemons are in Public Beta on all plans, including Hobby, within each plan's quotas. They are for long-running background workers that run next to an app in the same project. The release came with two other backend changes announced at Vercel Ship in San Francisco, covered in the Daemons documentation: Vercel Python support is now generally available, and container support in Vercel Functions now allows custom runtimes and system libraries.
What daemons are for
A daemon runs a process from a container image and keeps it running between jobs. Daemons cannot receive inbound network traffic. They pull work from a queue, a workflow engine or an external API. Vercel lists these uses:
- Queue consumers that poll Vercel Queues, Amazon SQS, Kafka or Redis, including Celery, Sidekiq and BullMQ workers.
- Workflow workers that retrieve tasks from a workflow engine.
- Job runners, such as self-hosted CI runners that wait for jobs.
How they are set up
Each daemon is declared under a top-level daemons key in vercel.json or vercel.toml, with a root, an entrypoint (a Dockerfile or Containerfile) and a replicas count per region. For example, "replicas": { "iad1": 2 } runs two instances in Washington, D.C. Daemons sit alongside Services, so a Next.js frontend and a FastAPI backend can have BullMQ and Celery workers next to them.
Vercel builds each image, pushes it to Vercel Container Registry and rolls the daemons out when a deployment becomes the production deployment, including after a promotion or rollback. It restarts instances that exit or crash, and forwards stdout and stderr to the project's Logs. Daemons run on Fluid compute. Each instance gets the deployment's environment variables and an OIDC token, written to a file whose path is in VERCEL_OIDC_TOKEN_FILE.
Scaling and shutdown
Instance counts can be changed by deploying new replicas values or by setting a scaling override, which needs no new deployment and stays in place across deployments until cleared. To stop an instance, Vercel sends SIGTERM and waits 10 seconds by default before terminating the process. This happens during rollouts, when instance counts are reduced and when a daemon is removed. Vercel advises making jobs idempotent, for example by acknowledging a queue message only after processing it.
Beta limits
Daemons run only in production environments. Preview deployments, autoscaling, persistent storage and projects with a root directory in a subfolder are not supported. vercel dev does not run daemons and prints a warning, so a worker is run locally with Docker instead.
Python and containers
Python on Vercel is generally available. FastAPI, Flask and Django run on standard CPython with PyPI dependencies. Vercel says 150,000 teams run Python backends on it. The container runtime deploys applications in any language as Vercel Functions on Fluid compute. Vercel says 5,000 teams have shipped 150,000 container deployments since it entered Public Beta.