Vercel passe Python en GA et lance Daemons pour les workers en arrière-plan

À la conférence Vercel Ship, à San Francisco, Vercel a élargi l'éventail des charges backend exécutables sur sa plateforme. Python passe en general availability. Les conteneurs de Vercel Functions permettent d'utiliser ses propres runtimes et bibliothèques système. Vercel Daemons, en bêta publique, fournit des workers d'arrière-plan qui ne se mettent pas en veille entre deux tâches. Les seuls backends Python sont aujourd'hui hébergés par 150 000 équipes, dont des ingénieurs d'OpenAI, de Polymarket et d'Exa.

Python : des frameworks sur CPython standard

L'entreprise prolonge la dynamique de l'an dernier, qui avait vu arriver la configuration zéro pour Python et TypeScript. Vercel Services, qui permet de déployer ensemble frontend et backend, est devenu disponible à l'été, de même que les files d'attente et les workflows durables. Python obtient désormais le statut GA. FastAPI, Flask et Django tournent sur un CPython classique avec les dépendances de PyPI, tandis que Vercel prend en charge la détection du framework, le build et la montée en charge. Le développement local, les previews et les déploiements en production fonctionnent comme pour un frontend.

Des SDK Python sont publiés séparément pour les produits de la plateforme : Vercel Blob pour les fichiers, Vercel Queues pour les tâches d'arrière-plan, Vercel Workflows pour les étapes durables, Vercel Sandbox pour l'exécution de code non fiable. L'AI SDK pour Python gère le streaming des réponses du modèle et le traitement des appels d'outils. Pour les équipes IA, c'est une pièce essentielle : Python reste le langage principal autour des modèles, et il n'est plus nécessaire de le déporter vers une infrastructure distincte.

Delphi, qui crée des « esprits » numériques à partir de livres et d'interventions, a présenté un cas parlant. L'entreprise a migré son backend Python d'AWS ECS vers Vercel. Son équipe compte dix ingénieurs et aucun rôle dédié à l'infrastructure. Elle déploie pourtant en production plus de 100 fois par jour et traite ses tâches d'arrière-plan via Queues. Spencer Shoben, Founding Engineer, affirme qu'avec Vercel, il n'a presque plus à penser à l'infrastructure.

Conteneurs et

Daemons : n'importe quel langage et des workers sans temps mort

Le runtime de conteneurs accepte des applications dans n'importe quel langage, avec les bibliothèques d'OS et les exécutables nécessaires. Depuis la bêta publique, 5 000 équipes ont effectué 150 000 déploiements de conteneurs. Les conteneurs sont déployés comme des Vercel Functions sur Fluid compute et suivent le trafic à la hausse comme à la baisse. Le modèle Active CPU s'applique : le temps passé à attendre les réponses d'API, les requêtes en base de données et l'inférence LLM n'est pas facturé. Ces charges sont placées derrière un CDN et un WAF, et les logs ainsi que les rollbacks permettent d'enquêter en cas d'incident.

Daemons répond à un autre besoin : un processus qui doit vivre en permanence. Le conteneur fonctionne comme un worker d'arrière-plan sur Fluid compute. Vous définissez le nombre d'instances dans chaque région, et Vercel maintient cette capacité en redémarrant les processus plantés ou terminés. Au lancement, seules les charges de type pull sont prises en charge : le code va lui-même chercher du travail auprès d'un autre système, par exemple en lisant des messages dans une file d'attente ou en récupérant des jobs dans une base de données.

Dans l'exemple de l'annonce, une application vidéo dont le frontend est en Next.js prépare, pour chaque vidéo téléversée, une copie de lecture et une miniature. Un Dockerfile basé sur python:3.12-slim installe ffmpeg et les dépendances, puis lance processor.py. Le fichier vercel.toml décrit le service frontend, le routage et le daemon videos, avec une seule instance dans la région iad1 (Washington).

• Python : GA, FastAPI, Flask, Django, dépendances de PyPI.
• Échelle : 150 000 équipes avec des backends Python.
• Conteneurs : 5 000 équipes et 150 000 déploiements pendant la bêta.
• Facturation : Active CPU, sans paiement du temps d'inactivité passé à attendre les API, les bases de données et les LLM.
• Daemons : bêta publique, nombre d'instances défini par région, redémarrage automatique.
• Mode de fonctionnement de Daemons au lancement : charges pull uniquement.

Par où commencer

La démarche la plus simple consiste à prendre un service Python existant sous FastAPI ou Django et à vérifier s'il passe en déploiement zero-config. Si vous avez besoin de ffmpeg, de bibliothèques natives ou d'un langage non standard, ajoutez un Dockerfile et déployez via Git ou la CLI Vercel : l'image sera construite et placée dans le Vercel Container Registry. Pour le traitement vidéo, les embeddings et les autres tâches longues qui vident une file d'attente, Daemons est un candidat logique.

Tenez compte des limites de la bêta : seul le modèle pull est géré pour l'instant, donc les workers qui attendent des connexions entrantes ne conviendront pas. Avant de migrer, comparez la facture avec l'actuelle : Active CPU est avantageux quand le service passe beaucoup de temps à attendre des réponses externes, et moins sensible sur des calculs constamment chargés.