Vercel Ship: Python reaches GA, containers land in Functions, Daemons enter public beta

At its Ship event in San Francisco, Vercel broadened the range of backend workloads its platform can run. According to the Vercel blog, Python support is now generally available, containers can be deployed as Vercel Functions with custom runtimes and system libraries, and a new product called Vercel Daemons has entered public beta for background workers that stay running between jobs.

Python reaches general availability

Vercel says Python backends now get the same development experience the platform already offered for frontends, including local development, preview deployments and production releases. Frameworks such as FastAPI, Flask and Django run on standard CPython with dependencies installed from PyPI, while Vercel handles framework detection, builds and scaling.

The company reports that 150,000 teams already run Python backends on its platform, including engineers at OpenAI, Polymarket and Exa. Python SDKs let applications call other Vercel products directly: Blob for file storage, Queues for background jobs, Workflows for coordinating durable steps, Sandbox for running untrusted code, and the AI SDK for streaming model responses and handling tool calls.

Vercel highlights Delphi, a company that builds AI digital minds from books and talks, as a customer example. Delphi moved its Python backend from AWS ECS to Vercel; with ten engineers and no dedicated infrastructure role, it ships to production more than 100 times a day and uses Queues to handle background work.

Containers as Vercel Functions

Container support, already available in public beta, lets teams deploy applications written in any language, packaged together with the OS libraries and executables they need. Vercel says 5,000 teams have shipped 150,000 container deployments since that beta opened.

Containers run as Vercel Functions on Fluid compute and scale with traffic. Billing follows an Active CPU model, which Vercel says does not charge for idle time spent waiting on API responses, database queries or LLM inferencing. Deployed containers also pick up the surrounding platform: Vercel Services for developing backend and frontend side by side, the CDN for delivery, the Vercel WAF for protection, plus logs and rollbacks. When you deploy through Git or the Vercel CLI, the platform builds the image and stores it in the Vercel Container Registry.

Daemons enter public beta

The newest piece is Vercel Daemons, which runs containers as continuously running background workers on Fluid compute. You configure how many instances run in each region, and Vercel maintains that capacity by restarting processes when they exit or crash. Daemons deploy in the same project as the rest of your application and are defined through a daemons entry in the configuration file at the project root, pointing at a Dockerfile or Containerfile.

At launch, Daemons targets pull-based workloads: code that requests work from another system and processes it as it arrives, rather than serving inbound requests. In its changelog post, Vercel lists concrete examples, including consumers using Vercel Queues poll mode, Celery, BullMQ, RabbitMQ or Kafka; Temporal or Cadence workers that long-poll their task queues; and self-hosted CI runners for GitHub Actions, GitLab or CircleCI that poll for jobs without inbound connections.

Because no HTTP server is required, a worker only needs its connection details set as production environment variables before deploying. Vercel writes that worker output appears in project logs, and CPU and memory metrics are available through Observability Plus.

Why it matters

Vercel built its business on frontend hosting and short-lived serverless functions, which made it a poor fit for stateful or long-running backend code. These announcements push the platform into territory long occupied by general-purpose cloud providers: arbitrary runtimes, background processing and always-on workers. The pricing model matters here too, since workloads that spend much of their time waiting on LLM responses or database queries, a common pattern in AI applications, are not billed for that idle time. For teams already running frontends on Vercel, being able to keep Python services, containers and daemons in the same project removes infrastructure work that previously had to live elsewhere, and the choice of examples, from queue consumers to Temporal workers and CI runners, signals that Vercel is courting backend and AI-heavy workloads directly.