Vercel Services transforme le déploiement en graphe de services

Tech

La limite de déploiement devient un graphe de services. vercel.json porte les services, rewrites publics, runtimes, entrypoints et bindings internes.

Diagramme d’un projet Vercel avec frontend Next.js, backend, worker et service privé reliés par rewrites et bindings
Vercel Services rend explicites les routes publiques et les bindings privés.

Ce qui a changé

Le 30 juin 2026, Vercel a présenté Services, qui permet de déployer plusieurs frontends et backends dans un même Vercel Project avec previews et rollbacks communs.

Pourquoi c’est important

La limite de déploiement devient un graphe de services. vercel.json porte les services, rewrites publics, runtimes, entrypoints et bindings internes.

Signal communauté

Les discussions Next.js montrent des préoccupations persistantes autour des backends séparés, timeouts, WebSockets, cron et coûts. Services répond à une partie de cette friction, mais concentre davantage de contrôle plateforme.

Actions concrètes

Relisez les diffs services, rewrites, bindings, testez l’ordre des routes, définissez l’authentification inter-services et observez le fan-out des appels internes.

Risques

Un binding n’est pas une autorisation applicative. Et comme Services est indiqué en beta, les charges critiques doivent attendre une répétition sur logs, rollback et coûts.

Checklist Services

Le 30 juin 2026, Vercel a présenté Services, qui permet de déployer plusieurs frontends et backends dans un même Vercel Project avec previews et rollbacks communs.

Relisez les diffs services, rewrites, bindings, testez l’ordre des routes, définissez l’authentification inter-services et observez le fan-out des appels internes.

Un binding n’est pas une autorisation applicative. Et comme Services est indiqué en beta, les charges critiques doivent attendre une répétition sur logs, rollback et coûts.

Sources