Vercel lance Vercel Services—déploiement unifié du frontend et du backend en un projet

Vercel a introduit une nouvelle capacité appelée Vercel Services, qui permet d'exécuter plusieurs frameworks — par exemple, un frontend Next.js et un backend FastAPI — au sein d'un seul Projet Vercel avec des déploiements partagés et une mise en réseau interne entre les services.

Comment configurer Vercel Services

Les services sont décrits dans le fichier vercel.json sous la clé "services" : pour chaque service, vous spécifiez le chemin (root) et le framework ou le point d'entrée (entrypoint), et le routage du trafic public est configuré via des rewrites. Le trafic public peut être dirigé uniquement vers le service frontend, laissant le backend accessible exclusivement de l'intérieur du projet.

• Configuration des services — via la clé "services" dans vercel.json
• Exemple de la documentation Vercel : service my_frontend sur Next.js et service my_backend sur FastAPI (entrypoint main:app)
• Le backend dans l'exemple n'a pas de route publique — accessible uniquement au service my_frontend via le réseau interne
• Le panneau Deployments affiche une visualisation du graphe des services, et l'interface Logs permet de filtrer les logs par service individuel
• La commande vercel dev lance automatiquement tous les services localement, répliquant l'environnement de production

Quel problème la combinaison de services résout-elle

Préalablement, les équipes qui combinaient un frontend JavaScript et, par exemple, un backend Python dans un seul produit devaient généralement les répartir sur différentes plates-formes cloud : Vercel a historiquement été fort dans le déploiement frontal basé sur Next.js, tandis que les services backend sur FastAPI, Django ou Flask allaient généralement sur des plates-formes d'hébergement séparées. En pratique, cela signifiait deux systèmes CI/CD indépendants, deux ensembles de logs et de surveillance, et une synchronisation manuelle des versions frontend et backend à chaque version. Vercel Services ferme cet écart : la configuration de plusieurs frameworks et services complets est décrite dans un fichier vercel.json, plutôt que d'être assemblée manuellement à partir des paramètres de différentes plates-formes.

Ce que les déploiements atomiques et les service bindings fournissent

Les déploiements atomiques garantissent que le frontend, le backend et les autres services du projet se déploient et se restaurent de manière synchronisée, et non séparément. Les déploiements de prévisualisation partagée montrent comment une seule modification affecte tous les services à la fois. Une configuration séparée des liaisons permet aux services de s'appeler directement, en contournant l'internet public : par exemple, la clé BACKEND_INTERNAL_URL est automatiquement transmise aux variables d'environnement du frontend et pointe vers l'adresse interne du backend.

Ce que cela signifie

Vercel Services ferme un écart de longue date entre les parties frontend et backend d'un seul produit, qui vivaient précédemment souvent dans des nuages différents avec leurs propres processus de développement et de déploiement. Pour les équipes combinant un frontend JavaScript et, par exemple, un backend Python sur FastAPI, cela signifie un déploiement unifié, un flux de prévisualisation partagé et une connectivité interne directe entre les services sans proxys inverses et configuration CORS. Pour la plate-forme, c'est aussi un moyen de conserver dans son écosystème les équipes qui ont précédemment quitté avec la partie backend du projet vers des hébergements tiers simplement parce que Vercel ne proposait pas de moyen pratique de garder toute la pile en un seul endroit.

Questions fréquemment posées

Qu'est-ce que Vercel Services ?

C'est une capacité de Vercel pour exécuter plusieurs services — par exemple, un frontend Next.js et un backend FastAPI — au sein d'un seul Projet Vercel avec routage partagé, déploiements atomiques et dimensionnement automatique ; la configuration est spécifiée dans vercel.json sous la clé "services".

Les services ont-ils besoin d'un proxy inverse pour communiquer entre eux ?

Non. Selon la documentation Vercel, les services peuvent être connectés à une table de routage partagée et leur interaction configurée via des liaisons sans proxy inverse et sans configuration CORS.