Vercel announced Daemons, a new service for running permanent background workers, in a move that expands the platform’s role from hosting front ends and request-based functions to running more parts of applications’ backend infrastructure. The service is currently available in public beta and allows developers to run a container and specify the desired number of instances in each region, while Vercel keeps the processes running and restarts them if they stop or fail.
Daemons targets workloads that pull tasks from a queue or database rather than waiting for an incoming request from the internet. This includes asynchronous processing, media conversion tasks, and work that requires continuous CPU consumption. According to Malte Ubl, Vercel’s CTO, the service represents the missing piece between request-based processing and persistent background tasks.
What does Daemons add for developers?
Workers can be deployed through Git or the Vercel CLI. Vercel builds the container image and stores it in the Container Registry, then manages the specified instances in each region. The company explains that a practical model could combine a Next.js-based front end with a Python API and a video processor running inside a container, with the processor pulling tasks from Vercel Queues and producing playable files and thumbnails.
Daemons differ from temporary Sandboxes; Sandboxes are intended for temporary execution, while Daemons remain running and do not receive requests directly from the internet. Instead, they connect to the work source and execute tasks when they become available. Vercel itself uses the service to move part of its asynchronous workloads, while saying that its control plane processes about one billion requests per month.
Containers versus managed runtimes
Vercel places Daemons within its expansion of container support. It says that 5,000 teams have carried out 150,000 container deployments since its support entered public beta. Containers give developers the freedom to include their own runtimes and system libraries, but updating the container’s security image and redeploying it remain the customer’s responsibility.
By contrast, Vercel handles security updates in its managed Node, Bun, and Python runtimes without requiring customers to redeploy. This means that choosing containers is not only about flexibility; it also entails an additional operational burden that teams must consider.
Python support and persistent storage for agents
Python support is now generally available for frameworks including FastAPI, Flask, and Django. Applications run on standard CPython with PyPI dependencies, while Vercel handles framework detection, building, and scaling. The company says that 150,000 teams already run Python backends on its platform, including engineers at OpenAI, Polymarket, and Exa.
Vercel has also made Drives generally available. It is persistent storage that separates an AI agent’s files from the Sandbox environment that executes the code. The agent can mount a Drive in a new Sandbox or change the runtime environment and continue working on the same files. Vercel says the service combines the characteristics of an EBS-like network-attached drive and object storage.
Why does this expansion matter?
Drives moves toward a model in which an agent’s important files are independent of its execution environment. Multiple agents can use a read-only copy of a dataset, or create writable branched copies to test different approaches, while keeping the branches separate from the original. The service provides a default capacity of 1 terabyte, or 1 gigabyte for the Hobby plan, with configurations of up to 16 terabytes.
In practice, these additions give teams that host their front ends on Vercel the option of keeping Python services, background workers, and persistent storage within the same platform instead of managing separate deployment systems. But this does not eliminate the trade-offs: containers require customers to track security updates, and Daemons are suited to continuous workloads that pull from a work source, not to every type of backend service or every processing pattern.