Vercel pricing : Turbo à la carte pour un seul déploiement

Côté Vercel pricing, la règle a changé le 17 septembre 2026 : Vercel permet désormais de payer Turbo pour un seul déploiement, sans l’imposer à tout le projet. On peut consacrer plus de budget à un build urgent, puis laisser le déploiement suivant revenir au choix de machine habituel du projet.

Vercel pricing : plus besoin de modifier le projet

Une machine de build est l’ordinateur temporaire que Vercel met à disposition du code pour installer les dépendances, compiler l’application et préparer le déploiement. Turbo est la plus puissante des options fixes : 30 vCPU, 60 GB de mémoire et 64 GB de disque.

Avant ce changement, choisir une machine de build fixe obligeait à modifier un réglage d’équipe ou de projet. Peu pratique face à une échéance serrée : il fallait soit payer Turbo pour les builds de prévisualisation courants, soit changer le réglage dans l’urgence et penser à le rétablir ensuite.

La nouvelle dérogation associe Turbo à un seul déploiement. Elle ne touche pas au réglage du projet. Si celui-ci utilise habituellement Basic, Standard ou Elastic, le déploiement suivant reprend ce choix, sauf si une nouvelle dérogation est ajoutée.

C’est tout l’intérêt : le surcoût de calcul suit l’urgence, pas chaque commit.

Turbo, Enhanced et Elastic sont accessibles avec les offres Pro et Enterprise. Les projets Hobby utilisent toujours Basic : ce n’est donc pas un accélérateur pour l’offre Hobby. L’option n’apporte rien non plus à un projet dont tous les déploiements tournent déjà sur Turbo.

Trois façons d’activer Turbo sur un seul déploiement

La méthode dépend de ce qui déclenche le déploiement. Dans les trois cas, la dérogation ne vaut que pour ce déploiement.

1. 1

   Ajouter le marqueur au commit GitHub

   Pour un déploiement déclenché par l’intégration GitHub de Vercel, ajoutez le marqueur exact et sensible à la casse dans le corps du message de commit :

   git commit -m "Test this change with Turbo" \
     -m "#VERCEL_BUILD_MACHINE=TURBO"

   Le marqueur s’applique uniquement au déploiement issu de ce commit. Pour l’instant, il ne fonctionne pas avec les intégrations GitLab ou Bitbucket de Vercel.

2. 2

   Passer par Vercel CLI

   Depuis un projet lié, exécutez :

   vc deploy --turbo

   Cette méthode nécessite Vercel CLI 59.20.0 ou une version ultérieure. Si le flag n’est pas reconnu, vérifiez d’abord que la CLI n’est pas trop ancienne.

3. 3

   Renseigner le champ de l’API de déploiement

   Si un service de release interne crée le déploiement via POST /v13/deployments, définissez buildMachine sur turbo dans la requête. Ce champ facultatif ne concerne que le déploiement et ne réécrit pas les réglages du projet.

Il faut disposer de l’autorisation nécessaire pour modifier la machine de build du projet. Un échec discret mérite d’être connu : si Turbo n’est pas disponible ou si le compte n’a pas les droits requis, Vercel utilise la machine habituelle du projet au lieu de faire échouer le déploiement.

Un coût limité ponctuellement, élevé par habitude

Vercel facture actuellement l’usage des builds à hauteur de $0.0035 par minute CPU. Les tarifs de départ par minute de build facturée sont donc de $0.007 pour Basic, $0.014 pour Standard lorsqu’il est facturé, $0.028 pour Enhanced et $0.105 pour Turbo.

Le compteur de facturation arrondit chaque build à la minute supérieure avant de multiplier la durée par le nombre de CPU de la machine. Un build Turbo de 3 minutes 40 secondes est ainsi facturé comme 4 minutes, soit $0.42.

Pour arbitrer entre Basic et Elastic à l’échelle du projet, consultez Réduire les coûts de build Vercel avec les machines Basic. La décision est ici plus ciblée : une échéance précise justifie-t-elle le surcoût de Turbo ?

Un exemple de charge, pas un benchmark

Prenons une équipe qui réalise 20 déploiements courants et 1 déploiement urgent dans la semaine. D’après ses propres mesures, la même charge prend 7 minutes 20 secondes sur Basic et 3 minutes 40 secondes sur Turbo. Ces durées sont fictives et servent uniquement au calcul. Turbo ne divisera pas systématiquement chaque build par deux.

La dérogation urgente ajoute $0.364 par rapport à l’exécution de ce déploiement sur Basic. Dans cet exemple, ce supplément permet de gagner 3 minutes 40 secondes sur la release qui compte.

En gardant les 20 builds courants sur Basic, le total hebdomadaire est inférieur de $7.28 à celui des 21 builds exécutés sur Turbo. Voilà, en une phrase, le nouveau levier budgétaire. La vraie décision doit toutefois s’appuyer sur vos propres durées : état du cache, usage du CPU, pression mémoire et arrondis peuvent tous modifier le résultat.

À qui ce workflow est-il vraiment utile ?

Un fondateur solo qui déploie un correctif en production

Le fondateur d’un SaaS relié à GitHub peut ajouter le marqueur au commit d’un seul hotfix. Le bénéfice n’est pas d’accélérer durablement le projet, mais de réduire l’attente pour la release liée à une panne, une promesse client ou une fenêtre de lancement, puis de revenir aux dépenses normales dès le push suivant.

Un responsable de release en agence face à une échéance

Une agence peut lancer vc deploy --turbo pour la release client que plusieurs personnes attendent avant validation. Les prévisualisations courantes restent sur la configuration habituelle du projet, ce qui évite de gonfler discrètement la facture des builds à chaque révision client.

Un ingénieur plateforme avec un circuit d’approbation

Une équipe plateforme peut réserver buildMachine: "turbo" au parcours approuvé des releases urgentes dans son service de déploiement. Le calcul supplémentaire devient ainsi une décision explicite, traçable, vérifiable et chiffrable, plutôt qu’un réglage permanent du projet.

Les limites à connaître

Avec trente vCPU, un build ne sera pas nécessairement 15 fois plus rapide qu’avec les 2 vCPU de Basic. Certaines charges ne peuvent pas occuper tous ces cœurs. Vercel indique que de nombreux projets n’exploitent pas entièrement une machine Turbo, ce qui explique aussi pourquoi Elastic peut retenir une machine plus petite pour les tâches courantes.

Turbo change également la machine, pas la politique de file d’attente. Si le retard vient surtout de l’attente d’un créneau de build, une machine plus puissante risque de résoudre le mauvais problème. Avant de payer davantage de CPU, comparez le temps passé dans la file au temps consacré au build.

L’état du cache peut lui aussi fausser la comparaison. Opposer un build standard avec cache chaud à un build Turbo avec cache froid ne permet pas d’isoler l’effet de la machine. Comparez des révisions et des conditions de cache similaires, en tenant compte des minutes facturées autant que du temps réel.

Mener un essai contrôlé

1. 1

   Mesurer le déploiement habituel

   Ouvrez Build Diagnostics et relevez la machine habituelle du projet, la durée du build, le temps d’attente, les minutes facturées et le résultat. Choisissez un déploiement représentatif de la charge urgente qui vous intéresse.

2. 2

   Forcer Turbo sur un déploiement

   Utilisez le marqueur GitHub, le flag de la CLI ou le champ de l’API sur un déploiement comparable. Ne modifiez pas le réglage de machine de build de l’équipe ou du projet.

3. 3

   Chiffrer le gain observé

   Multipliez les minutes de build Turbo, arrondies à la hausse, par $0.105. Comparez cette somme à l’usage facturé du déploiement habituel, puis divisez le surcoût en dollars par le nombre de minutes réellement gagnées.

4. 4

   Contrôler le déploiement suivant

   Lancez un nouveau déploiement normal, sans marqueur, flag ni champ d’API. Vérifiez qu’il utilise la machine habituelle du projet. Vous détecterez ainsi une modification accidentelle du réglage global et confirmerez que la dérogation est bien restée temporaire.

Que faut-il faire maintenant ?

• Agissez cette semaine si un projet Pro ou Enterprise connaît parfois des releases dictées par une échéance et que son réglage de machine habituel doit rester inchangé.
• Mesurez d’abord si le projet utilise Elastic. Il lui attribue peut-être déjà assez de CPU et de mémoire ; imposer Turbo pourrait alors alourdir la facture sans réduire sensiblement la durée.
• Préférez un réglage de projet si la plupart des déploiements ont besoin de Turbo. Répéter une exception à chaque commit revient à masquer une politique derrière un flag.
• Passez votre chemin avec l’offre Hobby, si Turbo est déjà le choix par défaut ou si le retard vient principalement de la file d’attente.

L’action à lancer lundi

Choisissez lundi un déploiement représentatif. Mesurez le build habituel, appliquez Turbo une fois, calculez le supplément au regard du temps réellement gagné, puis envoyez un déploiement normal et vérifiez que le projet est revenu à sa configuration habituelle.

Inscrivez-vous à la newsletter pour recevoir des analyses claires sur les évolutions des plateformes qui changent le budget ou le workflow.