Vercel adds always-on workers and stable Python to its platform

Vercel has taken advantage of its Ship conference in San Francisco to expand the ground where it wants to compete: the backend. The company has presented Daemons, a service for running background workers continuously, has declared its support for Python generally available, and has done the same with Drives, its persistent storage designed for AI agents. For a small business that already has part of its stack on the platform, the news is not minor: it stops being just a place to host the frontend and starts covering more pieces of the system.

What Daemons are and why they matter

Daemons, in public beta, allows you to deploy a container and specify how many instances should run in each region. Vercel takes care of keeping those processes alive and restarting them if they terminate or fail. In its first version it supports pull-based workloads: the worker queries a queue or database, picks up the work and processes it as it arrives.

The company's CTO, Malte Ubl, explains that the platform already covered tasks triggered by requests with its queues, its durable workflows and its Services function, which allows deploying frontend and backend together. What was missing was work that does not fit that pattern: heavy processing on a queue. Vercel's own deployment pipeline is the example Ubl gives: when its API is called to make a deployment, that deployment does not run in the process handling the request, because you cannot launch infinite concurrent deployments. GitHub's limits are one reason to moderate the pace, and the previous compute primitives did not give good control over the concurrency of that type of worker.

The use case the company illustrates combines a frontend in Next.js with an API in Python and a video processor in a container. That container packages Python dependencies and FFmpeg, and keeps picking up jobs from Vercel Queues to generate playback files and thumbnails. It is transcoding, a CPU-intensive workload where what is needed is a machine that is always at 100%. Daemons thus sit at the opposite end from Vercel's sandboxes: they are not ephemeral nor invoked by a request from the internet, but rather go out to look for work.

Managed runtime or container: the underlying debate

The arrival of Daemons forces us to consider how the code is packaged. Vercel claims that 5,000 teams have made 150,000 container deployments since the support entered public beta. Containers allow you to bring the application with its own runtime and its system libraries, which expands the catalog of deployable software. The price is who keeps the image up to date.

With a managed runtime for Node, Bun or Python, Vercel applies security patches without the customer having to redeploy, according to Ubl. With a container, you have to redeploy and the responsibility is the customer's: from the platform's point of view, they are just bytes. It is a nuance that in a small business with a small IT team makes the difference between an assumable operational burden and one that accumulates.

In parallel, Python support is now stable for frameworks such as FastAPI, Flask and Django. Applications run on standard CPython with PyPI dependencies, and Vercel takes care of framework detection, compilation and scaling. The company claims that 150,000 teams already run Python backends on its platform.

Drives: storage for agents that survives the sandbox

Vercel Drives separates an agent's files from the sandbox that runs its code. The agent can mount the drive in a new sandbox, change runtime and keep working with the files it had already created. Ubl describes it as a hybrid between a network disk like EBS and object storage: writes land on local NVMe disk and are sent asynchronously to object storage, while reads come from the local disk if the data is already there or are fetched in blocks.

The comparison with snapshots is deliberate. Ubl argues that snapshots grow a lot because they end up capturing things that are the same in every execution, whereas drives, being files in S3, are cheap to operate in large quantities. It is a discussion that will remain open, but it points to a clear trend: agents are changing the requirements of backend storage.

What it means for a small business and what we recommend

For an IT team with limited resources, the practical reading is that Vercel is expanding its catalog toward workloads that previously forced you to set up separate infrastructure. That can simplify operations, but it also concentrates more dependency on one provider. Before jumping in, it is worth reviewing these points:

• Classify your workloads. Separate what responds to requests from what processes queues: report generation, transcoding, synchronizations. Only the latter fits in Daemons.
• Decide managed runtime or container. If you choose a container, assume the cost of redeploying for security patches. If you do not have someone to watch over it, the managed runtime is usually the better option.
• Test in beta with non-critical workloads. Daemons is in public beta; it is not the place for the process that bills every night.
• Measure concurrency. The advantage of pull-type workers is controlling how many instances run; take advantage of it to avoid paying for idle compute.
• Review agent storage. If you are building AI workflows, evaluate whether Drives fits better than snapshots for the files that must persist.

The news fits a trend we have already been seeing: cloud providers want to cover more layers of the stack so that the customer does not leave their platform. On the blog we have analyzed similar moves in the field of AI and security, such as Nvidia's agentic model for laptops or the control of vibe-coding applications with Cloudflare Void. The difference here is that Vercel does not sell AI, but rather the substrate where to run it and where to run the usual backend. For a small business, the useful question is not whether the platform is more powerful, but whether the team can take on the operation that this power implies. Our recommendation: pilot Daemons with a real but secondary workload, document who maintains the images if you opt for containers, and review the exit cost before moving critical processes.

Source: The New Stack. Analysis and adaptation: ForgeNEX.