Vercel-Build-Kosten: Turbo gezielt pro Deployment aktivieren

Seit dem 17. September 2026 lassen sich Vercel-Build-Kosten punktuell steuern: Vercel macht Turbo zu einer Entscheidung pro Deployment statt zu einer Verpflichtung für das gesamte Projekt. Für einen dringenden Build kann damit mehr Rechenleistung gebucht werden; schon das nächste Deployment kehrt zur regulär gewählten Maschine des Projekts zurück.

Vercel-Build-Kosten steuern, ohne die Projekteinstellung zu ändern

Eine Build-Maschine ist der temporäre Rechner, den Vercel dem Code bereitstellt, während Abhängigkeiten installiert, die Anwendung kompiliert und das Deployment vorbereitet wird. Turbo ist die größte Option mit fester Ausstattung: 30 vCPUs, 60 GB Arbeitsspeicher und 64 GB Speicherplatz.

Vor dieser Änderung erforderte die Wahl einer festen Build-Maschine eine Anpassung auf Team- oder Projektebene. Für einen kurzfristigen Engpass war das unpraktisch: Entweder lief auch jeder gewöhnliche Preview-Build kostenpflichtig auf Turbo, oder die Einstellung musste für den eiligen Build geändert und anschließend wieder zurückgesetzt werden.

Der neue Override weist Turbo genau einem Deployment zu. Die Projekteinstellung bleibt unverändert. Nutzt ein Projekt normalerweise Basic, Standard oder Elastic, greift beim folgenden Deployment wieder diese Auswahl – es sei denn, ein weiterer Override wird gesetzt.

Genau darin liegt der Nutzen: Zusätzliche Build-Ausgaben richten sich nach der Dringlichkeit und nicht mehr nach jedem Commit.

Turbo, Enhanced und Elastic stehen in Pro und Enterprise zur Verfügung. Hobby-Projekte verwenden immer Basic; als Geschwindigkeitsschalter für Hobby ist das Feature daher nicht gedacht. Ebenso wenig bringt es Projekten, die ohnehin jedes Deployment auf Turbo ausführen.

Turbo für genau ein Deployment: drei Wege

Welche Methode passt, hängt davon ab, wodurch das Deployment ausgelöst wird. Alle drei Varianten setzen denselben Override für ein einzelnes Deployment.

1. 1

   Den GitHub-Marker im Commit verwenden

   Bei einem Deployment über die GitHub-Integration von Vercel gehört der exakte Marker unter Beachtung der Groß- und Kleinschreibung in den Text der Commit-Nachricht:

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

   Der Marker gilt nur für das Deployment aus diesem Commit. Über die GitLab- oder Bitbucket-Integration von Vercel funktioniert er derzeit nicht.

2. 2

   Die Vercel CLI verwenden

   In einem verknüpften Projekt genügt:

   vc deploy --turbo

   Dafür ist Vercel CLI 59.20.0 oder neuer erforderlich. Wird das Flag nicht erkannt, sollte deshalb zuerst die installierte CLI-Version geprüft werden.

3. 3

   Das Feld in der Deployment-API setzen

   Erstellt ein interner Release-Dienst das Deployment über POST /v13/deployments, muss die Anfrage buildMachine auf turbo setzen. Das optionale Feld gilt nur für dieses Deployment und überschreibt keine Projekteinstellungen.

Erforderlich ist die Berechtigung, die Build-Maschine des Projekts zu ändern. Dabei gibt es einen leicht zu übersehenden Fehlerfall: Ist Turbo nicht verfügbar oder fehlen dem Konto die nötigen Rechte, verwendet Vercel die reguläre Maschine des Projekts, statt das Deployment fehlschlagen zu lassen.

Einmal überschaubar, als Gewohnheit teuer

Vercel berechnet die Build-Nutzung derzeit mit $0.0035 pro CPU-Minute. Daraus ergeben sich Einstiegspreise von $0.007 je abgerechneter Build-Minute für Basic, $0.014 für Standard, sofern es abgerechnet wird, $0.028 für Enhanced und $0.105 für Turbo.

Für die Abrechnung wird jeder Build zunächst auf die nächste volle Minute aufgerundet und erst danach mit der CPU-Anzahl der Maschine multipliziert. Ein Turbo-Build mit einer Laufzeit von 3 Minuten und 40 Sekunden wird somit als 4 Minuten berechnet und kostet $0.42.

Für die grundlegende Entscheidung zwischen Basic und Elastic auf Projektebene gibt es den Beitrag Vercel-Build-Kosten mit Basic-Maschinen senken. Hier geht es um eine engere Frage: Ist eine einzelne Deadline den Turbo-Aufpreis wert?

Rechenbeispiel für einen Workload, kein Benchmark

Angenommen, ein Team veröffentlicht innerhalb einer Woche 20 reguläre Deployments und 1 dringendes Deployment. Eigene Messungen des Teams ergeben für denselben Workload 7 Minuten und 20 Sekunden auf Basic sowie 3 Minuten und 40 Sekunden auf Turbo. Diese Laufzeiten dienen nur der Rechnung und sind frei gewählt. Turbo halbiert nicht jeden Build.

Der einmalige Override erhöht die Kosten gegenüber einem Basic-Lauf dieses Deployments um $0.364. Im Beispiel erkauft dieser Aufpreis beim entscheidenden Release eine gemessene Zeitersparnis von 3 Minuten und 40 Sekunden.

Bleiben die 20 regulären Builds auf Basic, liegt die Wochensumme $7.28 unter den Kosten für alle 21 Builds auf Turbo. Genau diese Budgetkontrolle ermöglicht die neue Funktion. Für die tatsächliche Entscheidung zählen die eigenen Laufzeiten, denn Cache-Zustand, CPU-Auslastung, Speicherdruck und Rundung können das Ergebnis verschieben.

Für wen daraus ein sinnvoller Workflow entsteht

Solo-Founder mit einem Produktions-Hotfix

Bei einem über GitHub angebundenen SaaS kann ein Solo-Founder den Marker an genau den Hotfix-Commit hängen. Der Vorteil ist kein dauerhaft schnelleres Projekt, sondern eine kürzere Wartezeit für das Release, das einen Ausfall, ein Kundenversprechen oder ein Launch-Fenster betrifft. Beim nächsten Push gelten wieder die normalen Kosten.

Release-Verantwortliche in einer Agentur mit fester Deadline

Eine Agentur kann vc deploy --turbo für das Kunden-Release einsetzen, auf dessen Review bereits Beteiligte warten. Gewöhnliche Previews bleiben auf der üblichen Projektkonfiguration. So wächst der Build-Posten nicht unbemerkt mit jeder Korrekturschleife des Kunden.

Plattform-Engineering mit Freigabeprozess

Ein Plattformteam kann buildMachine: "turbo" im eigenen Deployment-Dienst ausschließlich für einen freigegebenen Pfad zu dringenden Releases setzen. Zusätzliche Rechenleistung wird damit zu einer ausdrücklichen Release-Entscheidung, die sich protokollieren, prüfen und kalkulieren lässt, statt dauerhaft als Projektstandard zu gelten.

Die Grenzen von Turbo

Dreißig vCPUs bedeuten nicht, dass ein Build 15-mal schneller läuft als mit den 2 vCPUs von Basic. Manche Builds können nicht alle Kerne auslasten. Laut Vercel schöpfen viele Projekte eine Turbo-Maschine nicht vollständig aus – auch deshalb kann Elastic für reguläre Workloads eine kleinere Maschine wählen.

Turbo ändert außerdem die Maschine, nicht die Warteschlangenregeln. Entsteht die Verzögerung überwiegend beim Warten auf einen Build-Slot, löst eine größere Maschine womöglich das falsche Problem. Vor zusätzlichen CPU-Ausgaben sollte daher die Zeit in der Warteschlange mit der eigentlichen Build-Zeit verglichen werden.

Auch der Cache-Zustand kann einen Vergleich unbrauchbar machen. Ein warmer Standard-Build und ein kalter Turbo-Build zeigen nicht, welchen Unterschied die Maschine verursacht hat. Sinnvoll sind ähnliche Revisionen und Cache-Bedingungen; neben der verstrichenen Zeit gehören auch die abgerechneten Minuten in den Vergleich.

Ein kontrollierter Test schafft Klarheit

1. 1

   Das reguläre Deployment erfassen

   In Build Diagnostics die normale Maschine des Projekts, Build-Dauer, Wartezeit, abgerechnete Minuten und Ergebnis festhalten. Als Ausgangspunkt eignet sich ein Deployment, das dem relevanten dringenden Workload möglichst ähnlich ist.

2. 2

   Ein Deployment gezielt überschreiben

   Den GitHub-Marker, das CLI-Flag oder das API-Feld für ein vergleichbares Deployment verwenden. Die Build-Maschine weder auf Team- noch auf Projektebene ändern.

3. 3

   Die gemessene Zeitersparnis bepreisen

   Die aufgerundeten Turbo-Build-Minuten mit $0.105 multiplizieren. Diesen Betrag der abgerechneten Nutzung des regulären Deployments gegenüberstellen und anschließend die Mehrkosten durch die tatsächlich eingesparten Minuten teilen.

4. 4

   Das darauffolgende Deployment kontrollieren

   Ein weiteres reguläres Deployment ohne Marker, Flag oder API-Feld auslösen. Anschließend prüfen, ob wieder die übliche Maschine des Projekts verwendet wird. So fällt eine versehentlich geänderte Projekteinstellung auf und zugleich ist belegt, dass der Override vorübergehend blieb.

Was jetzt sinnvoll ist

• Diese Woche umsetzen, wenn ein Pro- oder Enterprise-Projekt nur gelegentlich Releases unter Zeitdruck ausliefert und seine reguläre Maschineneinstellung behalten soll.
• Zuerst messen, wenn das Projekt Elastic verwendet. Möglicherweise weist Elastic bereits genügend CPU und Arbeitsspeicher zu; erzwungenes Turbo kann dann die Rechnung erhöhen, ohne nennenswert Zeit zu sparen.
• Stattdessen die Projekteinstellung nutzen, wenn die meisten Deployments Turbo benötigen. Eine Ausnahme bei jedem Commit zu wiederholen, ist letztlich eine Richtlinie in Gestalt eines Flags.
• Ignorieren, wenn das Projekt auf Hobby läuft, ohnehin standardmäßig Turbo nutzt oder die Verzögerung hauptsächlich in der Warteschlange entsteht.

Der Schritt am Montag

Am Montag ein repräsentatives Deployment auswählen. Den regulären Build dokumentieren, einmal Turbo als Override ausführen und den Aufpreis der tatsächlich eingesparten Zeit gegenüberstellen. Danach ein normales Deployment anstoßen und prüfen, ob das Projekt wieder seine übliche Konfiguration nutzt.

Den Newsletter abonnieren, um verständliche Einordnungen zu Plattformänderungen zu erhalten, die Budget oder Workflow tatsächlich beeinflussen.