Vercel Kosten senken: Wann sich Basic Build Machines lohnen

Nicht der günstigere Minutenpreis entscheidet über die Vercel Kosten. Seit dem 3. September 2026 bietet Vercel Pro- und Enterprise-Teams eine neue Basic-Option mit 2 vCPUs, 8 GB Arbeitsspeicher und einem Preis von $0.007 pro Build-Minute. Die Rechnung sinkt jedoch nur, wenn die Kosten je abgeschlossenem Build nach Laufzeit, Rundung, Fehlschlägen und Wartezeit unter denen von Elastic liegen.

Was Vercel geändert hat

Eine Build-Maschine ist der temporäre Rechner, auf dem Vercel Abhängigkeiten installiert, die App kompiliert und das Deployment vorbereitet. Kostenpflichtige Projekte haben nun eine kleinere feste Option: Basic Build Machines stehen für Pro und Enterprise zur Verfügung, nicht mehr nur für Hobby.

Basic bietet 2 vCPUs, 8 GB Arbeitsspeicher und 32 GB Speicherplatz. Elastic kann je nach Projektlast 4 bis 30 vCPUs und 8 bis 60 GB Arbeitsspeicher zuweisen. Für neue kostenpflichtige Projekte bleibt Elastic die Voreinstellung.

Es handelt sich um eine Wahlmöglichkeit, nicht um eine neue kostenpflichtige Voreinstellung. Neue Bezahlprojekte starten weiterhin mit Elastic; Basic lässt sich in den Team- oder Projekteinstellungen durch eine Person mit Eigentümerrolle auswählen. Hobby-Projekte behalten dieselbe enthaltene Maschine mit 2 vCPUs, die jetzt Basic heißt.

Hier geht es ausschließlich um die Wahl der Build-Maschine. Plangebühr, Nutzungsguthaben, Nutzerplätze, Traffic, Functions, Speicher und Add-ons gehören weiterhin in den vollständigen Überblick zu den Vercel Preisen.

Vercel Kosten vergleichen: Entscheidend ist der Preis pro erfolgreichem Build

Basic und Elastic beginnen beim selben CPU-Tarif: $0.0035 pro CPU-Minute. Die Rechnungsbeträge unterscheiden sich, weil Basic stets 2 vCPUs nutzt, während Elastic zwischen 4 und 30 zuweist.

Vercel rundet die Dauer jedes Builds auf die nächste volle Minute auf. Daraus ergeben sich zwei praxistaugliche Formeln:

• Basic: aufgerundete Build-Minuten × $0.007.
• Elastic: aufgerundete Build-Minuten × zugewiesene vCPUs × $0.0035.

Bei der kleinsten Elastic-Zuweisung mit 4 vCPUs beträgt der Einstiegspreis $0.014 je abgerechneter Build-Minute. Basic kostet pro abgerechneter Minute halb so viel. Damit herrscht Kostengleichheit, wenn Basic genau doppelt so viele abgerechnete Minuten benötigt; bleibt die Laufzeit darunter, ist Basic günstiger.

Diese Regel verschiebt sich, sobald Elastic mehr als 4 vCPUs zuweist. Auch an jeder Minutengrenze ändert sie sich, denn Vercel rundet die Dauer jedes einzelnen Builds und nicht die Monatssumme. Für eine belastbare Rechnung zählen daher die tatsächliche Laufzeit und die zugewiesene Maschine, nicht eine Schätzung anhand der Preisliste.

Die Ersparnis von $7 ist in diesem Beispiel real, muss aber nicht wertvoll sein. Wenn jeder Preview-Build eine Entwicklerin, einen Reviewer oder einen Coding-Agent aufhält, kann die langsamere Feedbackschleife mehr kosten als die Ersparnis auf der Rechnung. Laufen die Builds dagegen im Hintergrund und bleibt die Warteschlange frei, liefert Basic die besseren Stückkosten.

Auch Fehlschläge gehören in den Zähler. Die relevante Betriebskennzahl lautet: gesamte Build-Gebühren geteilt durch erfolgreiche Deployments. Eine Maschine, die pro Minute günstig ist, aber Wiederholungen verursacht, kann beim eigentlich gekauften Ergebnis trotzdem teurer sein.

Wartezeit ist ein Kostenfaktor im Workflow

Die veröffentlichte Abrechnungsformel von Vercel berücksichtigt Build-Dauer und CPU-Anzahl. Wartezeit wird nicht als zusätzlicher Posten berechnet. Für das Team ist sie trotzdem spürbar.

Ist On-demand Concurrency deaktiviert, verfügt Pro über 3 parallele Deployment-Slots. Weitere Builds warten, solange diese Slots belegt sind. Mit On-demand Concurrency nennt Vercel bis zu 500 parallele Deployments und berechnet die genutzten Build-Minuten.

Ein langsamerer Basic-Build belegt einen Slot länger. Für einen Solo-Gründer, der eine kleine Website einige Male am Tag deployt, ist das womöglich unerheblich. Relevant wird es schnell, wenn ein Coding-Agent mehrere Previews öffnet, eine Agentur viele Kundenprojekte deployt oder ein Team gleichzeitig in mehrere Branches pusht.

Deshalb sollten beide Zeitwerte erfasst werden:

• Build-Dauer bestimmt nach der Rundung die Maschinenkosten.
• Wartezeit plus Build-Dauer bestimmt die Zeit bis zum Feedback.

Darauf läuft die Entscheidung hinaus: Den ersten Wert optimieren, ohne mit dem zweiten den Workflow auszubremsen.

Für wen sich ein Test mit Basic lohnt

Solo-Gründer mit einer kleinen App

Bei einem schlanken Marketingauftritt oder Dashboard kann ein Solo-SaaS-Gründer auf Projektebene zu Basic wechseln und anschließend denselben repräsentativen Build mit Elastic vergleichen. Der mögliche Vorteil: dauerhaft niedrigere Build-Kosten, ohne den restlichen Vercel-Plan anzutasten.

Der Wechsel lohnt sich nur dauerhaft, wenn der Build zuverlässig bleibt und eine mögliche längere Laufzeit keine Releases verzögert. Bei einem Projekt mit seltenen Deployments kann der Preisunterschied zu gering sein, um manuelle Optimierung zu rechtfertigen.

Agentur mit unterschiedlichen Kundenprojekten

Eine Agentur sollte die Maschinenwahl nicht pauschal für alle Kundenkonten treffen. Kleine Landingpages und Content-Projekte lassen sich einzeln auf Basic festlegen. Größere Shops, Monorepos und Apps mit vielen Abhängigkeiten bleiben auf Elastic, bis eigene Messwerte für einen Wechsel sprechen.

Der Nutzen liegt in einer saubereren Marge je Projekt. Ein ressourcenschonendes Kundenprojekt muss dann nicht mehr dieselbe Build-Maschine wie die anspruchsvollste App der Agentur verwenden.

Engineering Lead mit Coding-Agents

Agentengestützte Entwicklung verändert die Mengenkomponente der Rechnung. Mehr automatisierte Commits können mehr Preview-Builds auslösen, sodass sich schon ein kleiner Kostenunterschied je Build häufiger wiederholt.

Gemessen werden sollte deshalb eine repräsentative Lastspitze und nicht nur ein ruhiges Deployment. Senkt Basic zwar die Kosten je abgeschlossenem Build, belegen längere Laufzeiten aber alle 3 verfügbaren Slots und erzeugen eine Warteschlange, verlagert die günstigere Maschine Kosten von der Rechnung in die Durchlaufzeit.

Enterprise-Plattformverantwortliche

Basic steht auch für Enterprise zur Verfügung, doch ein Vertragsdetail kann eine eigenständige Umstellung verhindern. Enterprise-Kunden, bei denen Enhanced Machines vertraglich aktiviert sind, nutzen diese standardmäßig und müssen sich an ihren Account Manager wenden, um die Maschinenpräferenzen zu ändern.

Ein Projekt auf Basic umstellen und sauber testen

Zuerst empfiehlt sich die Änderung auf Projektebene. So bleibt das Experiment von anderen Apps getrennt und lässt sich über dieselbe Einstellung unkompliziert zurücknehmen.

1. 1

   Ausgangswert mit Elastic erfassen

   In Vercel Observability die Build Diagnostics öffnen und ein repräsentatives Deployment auswählen. Build-Dauer, zugewiesene Maschine, abgerechnete Nutzung, Wartezeit und Abschlussstatus festhalten. Cache-Bedingungen und Code-Revision sollten beim anschließenden Basic-Lauf vergleichbar sein.

2. 2

   Basic für das Projekt auswählen

   Das Projekt in Vercel öffnen und zu Settings, Build and Deployment und Build Machine wechseln. Basic auswählen und speichern. Vercel dokumentiert dieselbe Auswahl auf Teamebene, für einen ersten Test ist die Projekteinstellung jedoch sicherer. Für den Zugriff auf die Einstellungen der Build-Maschine ist die Eigentümerrolle erforderlich.

3. 3

   Den dokumentierten CLI-Weg verwenden

   Mit Vercel CLI 59.6.0 oder neuer lässt sich das Projekt über folgenden Befehl umstellen:

   vc project update --build-machine basic

   Ein typischer Fehler ist, den Befehl mit einer älteren CLI auszuführen und daraus zu schließen, die Maschinenwahl sei im eigenen Plan nicht verfügbar. Deshalb zuerst die Version prüfen, bevor ein fehlgeschlagener Befehl als Tarifbeschränkung gilt.

4. 4

   Dieselbe Arbeitslast ausführen

   Dieselbe repräsentative Revision unter vergleichbaren Cache-Bedingungen bauen. Erneut Build-Dauer, Maschine, abgerechnete Nutzung, Wartezeit und Abschluss erfassen. Bei agentengestützter Arbeit gehört eine typische Lastspitze dazu, damit eine mögliche Warteschlange sichtbar wird.

5. 5

   Nach Ergebnissen entscheiden

   Die monatlichen Build-Kosten berechnen und durch die erfolgreichen Deployments teilen. Basic bleibt die bessere Wahl, wenn diese Stückkosten sinken und die gesamte Durchlaufzeit weiterhin das Teamziel erfüllt. Das Projekt in den Build-Machine-Einstellungen wieder auf Elastic setzen, sobald Geschwindigkeit, Arbeitsspeicher oder Zuverlässigkeit so stark nachlassen, dass die Ersparnis verschwindet.

Die tatsächlichen Grenzen

Basic ist eine kleinere Maschine und keine effizientere Version von Elastic. Die Obergrenze von 8 GB Arbeitsspeicher ist fest. Elastic kann bei entsprechender Arbeitslast bis auf 60 GB und 30 vCPUs skalieren.

Auch die Rundung kann eine kleine Ersparnis aufzehren. Schon wenige Sekunden über einer Minutengrenze erzeugen eine weitere vollständig abgerechnete Minute. Maßgeblich ist die von Vercel ausgewiesene Nutzung und nicht eine Stoppuhrrechnung, die zugunsten von Basic abrundet.

Elastic passt sich außerdem an Veränderungen im Projekt an, Basic bleibt unverändert. Eine Maschinenwahl, die zur kleinen App von heute passt, kann falsch werden, sobald Abhängigkeiten, Routen oder generierte Assets zunehmen.

Wer jetzt handeln, warten oder nichts ändern sollte

• Diese Woche handeln, wenn ein Pro- oder Enterprise-Projekt stabile, ressourcenschonende Builds ausführt und das Build-Volumen groß genug ist, damit ein wiederkehrender Unterschied je Build ins Gewicht fällt.
• Abwarten, wenn das Projekt CPU-limitiert oder speicherintensiv ist, sich der Grenze von 45 Minuten nähert oder bereits empfindlich auf Preview-Warteschlangen reagiert. Zuerst einen verlässlichen Elastic-Ausgangswert ermitteln.
• Die Preisänderung ignorieren, wenn das Projekt im Hobby-Plan läuft. Die enthaltene Maschine mit 2 vCPUs heißt nun Basic, an der Maschine und ihrer Einordnung im Tarif ändert sich jedoch nichts.
• Zuerst den Vertrag prüfen, wenn für Enterprise Enhanced Machines aktiviert sind. Möglicherweise liegt die Umstellung beim Account Manager.

Der Schritt am Montag

Am Montag ein repräsentatives kleines Projekt auswählen. Denselben Build mit Elastic und Basic ausführen und dabei Dauer, abgerechnete Nutzung, zugewiesene CPUs, Wartezeit und Abschluss festhalten. Die Option behalten, die die Kosten je abgeschlossenem Build senkt, ohne das Durchlaufzeitziel des Teams zu verfehlen.

Newsletter abonnieren, um weitere verständliche Analysen zu Plattformänderungen zu erhalten, die Budget oder Workflow beeinflussen.