Vercel Takes Python to GA and Launches Daemons for Background Workers

At the Vercel Ship conference in San Francisco, Vercel expanded the range of backend workloads you can run on the platform. Python has reached general availability. Containers in Vercel Functions allow custom runtimes and system libraries. Vercel Daemons, in public beta, provide background workers that do not go to sleep between tasks. Python backends alone now serve 150,000 teams, including engineers at OpenAI, Polymarket and Exa.

Python: frameworks on standard CPython

The company is building on last year's work, when it introduced zero-configuration support for Python and TypeScript. By summer, Vercel Services had become available, letting teams deploy frontend and backend together, along with queues and durable workflows. Python now has GA status. FastAPI, Flask and Django run on regular CPython with dependencies from PyPI, while Vercel handles framework detection, builds and scaling. Local development, previews and production deployments work the same way as they do for frontends.

Vercel also released Python SDKs for its platform products: Vercel Blob for files, Vercel Queues for background tasks, Vercel Workflows for durable steps and Vercel Sandbox for running untrusted code. The AI SDK for Python handles streaming model responses and tool-call processing. For AI teams this is a key piece: Python remains the main language around models, and it no longer has to run on separate infrastructure.

Vercel pointed to Delphi as an illustrative case. The company builds digital "minds" from books and talks. It moved its Python backend from AWS ECS to Vercel. The team has ten engineers and no dedicated infrastructure role, yet it ships to production more than 100 times a day and processes background jobs through Queues. Founding Engineer Spencer Shoben says that with Vercel, he hardly has to think about infrastructure.

Containers and

Daemons: any language and workers without idle cost

The container runtime accepts applications in any language, together with the OS libraries and executables they need. Since the public beta began, 5,000 teams have made 150,000 container deployments. Containers deploy as Vercel Functions on Fluid compute and scale with traffic. The Active CPU model applies: time spent waiting for API responses, database queries and LLM inference is not billed. A CDN and WAF sit in front of these workloads, and logs and rollbacks are available for investigations.

Daemons address a different problem: a process that has to stay alive permanently. A container runs as a background worker on Fluid compute. You set the number of instances in each region, and Vercel maintains that capacity and restarts processes that crash or exit. At launch, Daemons support pull workloads: the code itself requests work from another system, for example by reading messages from a queue or picking up jobs from a database.

In the example from the announcement, a video app with a Next.js frontend prepares a playback copy and a thumbnail for every uploaded video. A Dockerfile based on python:3.12-slim installs ffmpeg and dependencies, then runs processor.py. The vercel.toml file defines the frontend service, routing and a videos daemon with one instance in the iad1 region (Washington).

• Python: GA, FastAPI, Flask, Django, dependencies from PyPI.
• Scale: 150,000 teams with Python backends.
• Containers: 5,000 teams and 150,000 deployments during the beta.
• Billing: Active CPU, with no charge for idle time spent waiting on APIs, databases and LLMs.
• Daemons: public beta, instance count set per region, automatic restart.
• Daemons mode at launch: pull workloads only.

Where to start

The easiest approach is to take an existing Python service on FastAPI or Django and check whether it fits a zero-config deployment. If you need ffmpeg, native libraries or a non-standard language, add a Dockerfile and deploy via Git or the Vercel CLI: the image will be built and pushed to Vercel Container Registry. For video processing, embeddings and other long-running tasks that work through a queue, Daemons are a logical candidate.

Keep the beta's limitations in mind: for now it is a pull model only, so workers that wait for incoming connections will not fit. Before migrating, compare the bill with your current one: Active CPU pays off where a service spends a lot of time waiting on external responses, and the savings are less noticeable for constantly loaded compute.