Vercel adds always-on Daemons, GA Python support and Drives for AI agents

Daemons for always-on workers

Vercel introduced Daemons at its Ship conference in San Francisco on Thursday. The service is in public beta and lets developers deploy a container and set how many instances run in each region. Vercel keeps the processes running and restarts them if they exit or crash. At launch, Daemons supports pull-based workloads, where workers fetch jobs from a queue or database and process them as they arrive.

CTO Malte Ubl said the move reflects a push further down the stack, with the goal of letting more teams use Vercel as their infrastructure provider. He contrasted the offering with request-driven work and described Vercel's own deployment pipeline as an example where deployments are not handled in the process that receives the API request. With Daemons, workers start, ask for work, and then process jobs. The company says 5,000 teams have made 150,000 container deployments since container support entered public beta.

A Next.js and Python worker example

Vercel's example combines a Next.js frontend with a Python API and a containerized video processor. The container packages Python dependencies and the FFmpeg media framework, then pulls jobs from Vercel Queues to generate playback files and thumbnails. Ubl described transcoding as an extremely CPU-bound workload that needs machines kept at 100% CPU. He said Daemons sit opposite the temporary sandbox model: they stay on, but they are not invoked by requests from the internet.

Python support reaches general availability

Vercel said Python support is now generally available for FastAPI, Flask and Django. Applications run on standard CPython with PyPI dependencies, while Vercel handles framework detection, builds and scaling. The company said 150,000 teams already run Python backends on the platform, including engineers at OpenAI, Polymarket and Exa.

On containers, Ubl said the trade-off is image maintenance. With a managed runtime for Node, Bun or Python, Vercel can apply a security release without a customer redeploying. With a container, he said, the image is ultimately the customer's responsibility because Vercel treats it as bytes. Developers can deploy Daemons through Git or the Vercel CLI, and Vercel builds the container image and stores it in its Container Registry.

Drives aims at files that outlive a sandbox

Vercel also made Drives generally available. The persistent storage service is for AI agents and separates an agent's files from the sandbox running its code. An agent can mount the drive in a new sandbox, change runtimes, and keep working with files it already created. Ubl called it a hybrid of an EBS-style networked drive and object storage, and said AWS does not offer that combination. Writes land on local NVMe disk and stream asynchronously to object storage, while reads use local disk when present or stream in block by block.

Ubl argued Drives are a better model than snapshots for agents because snapshots get large when they capture the same unchanged material. Mounting one working directory lets agents boot from the same cached base image. Drives can also let agents reuse each other's work: one agent can prepare a dataset while others mount read-only copies to analyze it or generate reports, and agents can fork a drive for separate writable test workspaces. He said those forks do not merge back into the original, so developers should tell the agent where to write, then mount that directory into the durable drive. Drives is available on all Vercel plans, with default capacities of 1 TiB, or 1 GiB on Hobby, and configurations up to 16 TiB.

Sources: The New Stack