Kör inte bytet direkt i projektets vardagsflöde. Skapa ett isolerat benchmarkprojekt för samma repo, lås en commit och kör minst fem kalla och fem varma byggen per alternativ. Spara byggtid, kötid, cacheutfall, faktisk maskintilldelning, resursfel och omkörningar. Välj Basic först när kostnaden per lyckat bygge klarar teamets gräns även i ett tungt scenario – och återställ Elastic om en hård gräns bryts.
Basic är ett fast val, Elastic är ett utfall
Den 3 september 2026 meddelade Vercel att Pro- och Enterprise-team kan välja Basic build machines. Enligt Vercels lanseringsnotis har Basic 2 vCPU och 8 GB minne. Tabellen över byggmaskiner anger dessutom 32 GB disk. Nya betalda projekt fortsätter att använda Elastic som standard, och Vercel rekommenderar Elastic för de flesta användningsfall.
Skillnaden är större än två produktnamn. Elastic kan enligt samma dokumentation tilldela 4–30 vCPU och 8–60 GB minne utifrån projektets observerade arbetslast. Du kan därför inte skriva in en fast Elastic-maskin i kalkylbladet före provet. Spara den maskintyp eller det vCPU-antal som Vercel faktiskt visar för varje körning; om uppgiften saknas ska kostnaden stå som okänd, inte fyllas med ett antagande.
Ett ändrat projektval påverkar efterföljande byggen. Koppla därför samma repo till ett separat benchmarkprojekt med samma rotkatalog, framework preset och bygginställningar. Då kan du växla Basic och Elastic utan att en vanlig produktionspush råkar hamna mitt i provet. Publicerings-, preview- och rollbackgrinden hör hemma i Monkeybases separata Vercel-flöde; här mäter du bara byggmaskinen.
1. Frys försöket innan första bygget
Skriv ett litet provprotokoll innan du tittar på resultat. Lås repository, branch och full commit-hash. Behåll samma låsfil, Node-version, paketmanager, installationskommando, byggkommando, rotkatalog, framework preset och miljövariabler. Spara ofarliga konfigurationsvärden direkt och jämför hash eller versions-id för hemligheter i stället för deras innehåll. Ändras någon av dessa faktorer börjar serien om.
commit: 4f8c2d1…
scenario: normal | heavy
machine: basic | elastic
cache_requested: cold | warm
cache_observed: hit | miss | partial | unknown
created_at_utc:
build_started_at_utc:
build_finished_at_utc:
assigned_vcpu:
status: success | failed
failure_class:
rerun_required: yes | no
Spara också maskinvalet som gällde före testet. Basic kan väljas i team- eller projektinställningen. Med Vercel CLI 59.6.0 eller senare visar lanseringsnotisen kommandot vc project update --build-machine basic. Använd bara en konfigurationsväg under försöket och dokumentera hur ursprungsläget ska återställas. Undvik samtidigt andra ändringar i projektet; annars vet du inte om skillnaden kom från maskinen eller konfigurationen.
2. Separera kall cache, varm cache och kö
Kör fem kalla och fem varma normalbyggen på Basic och upprepa samma matris på Elastic. En kall körning är här en Redeploy av den låsta committen där Use existing Build Cache är avmarkerad. Det stöds av Vercels felsökningsguide för byggen. En varm körning är samma Redeploy med befintlig build cache. Skriv ändå upp det observerade cacheutfallet från loggen; ett begärt varmt bygge är inte bevis för en faktisk träff.
Kör ett oregistrerat uppvärmningsbygge efter varje maskinbyte och växla sedan ordningen mellan blocken, exempelvis Basic–Elastic för kalla körningar och Elastic–Basic för varma. Starta bara ett benchmarkbygge åt gången. Vercels byggdokumentation beskriver att nya byggen väntar när samtidighetsplatserna är upptagna. Beräkna därför queue_seconds från skapad tid till byggstart och build_seconds från byggstart till byggslut. En lång kö säger inget säkert om CPU-prestandan.
Rapportera fördelningen, inte rekordet
För varje cell redovisar du median, snabbaste och långsammaste lyckade bygge samt antal fel och omkörningar. Ett snabbt cachebygge får inte ensamt representera maskinen. Om någon körning stördes av en dokumenterad extern incident kan den markeras separat, men radera den inte tyst.
3. Lägg in ett tungt bygge som kan misslyckas
Normalbygget visar vardagen men inte klippkanten. Definiera därför ett tungt scenario i samma commit: kör exempelvis hela monorepot i stället för ett paket, aktivera en incheckad fixture med projektets dyraste sidgenerering eller kör den fulla typkontroll och bundling som annars bara används inför release. Arbetsmängden måste vara deterministisk, versionshanterad och identisk på båda maskinvalen. Ett slumpmässigt stresstest som gör olika arbete mellan körningarna kan inte avgöra maskinfrågan.
Kör tre kalla tunga byggen per alternativ. Spara slutstatus, sista relevanta loggrad och eventuell systemrapport om minne eller disk tar slut. Ett misslyckat försök följt av en lyckad omkörning räknas som två körningar i kostnaden och som extra ledtid i arbetsflödet. Gör inte Basic godkänt genom att bara jämföra de försök som till slut lyckades.
4. Räkna kostnad per lyckat bygge
För betalda team anger Vercels prissida 0,0035 USD per CPU-minut. Basic blir därmed 0,007 USD per byggminut med sina 2 vCPU. Byggtiden avrundas uppåt till närmaste minut före multiplikationen. Elastic börjar på samma CPU-minutpris men använder det vCPU-antal som tilldelades körningen. Alla belopp här är USD och exkluderar skatt samt andra Vercel-resurser.
avrundade_minuter = ceil(build_seconds / 60)
basic_usd = avrundade_minuter × 0.007
elastic_usd = avrundade_minuter × assigned_vcpu × 0.0035
kostnad_per_lyckat_bygge =
kostnad_för_alla_försök / antal_lyckade_byggenExempel: om Basic behöver 181 sekunder blir debiteringsunderlaget 4 byggminuter, alltså 0,028 USD. Om Elastic behöver 119 sekunder och faktiskt visar 4 vCPU blir underlaget 2 × 4 CPU-minuter, också 0,028 USD. Exemplet illustrerar avrundningen, inte ett förväntat resultat. Fakturan är facit, och priset ska kontrolleras igen när beslutet verkställs. Blanda inte heller byggkostnaden med användarbudgetar för modelltrafik; de hanteras i provet för Vercel AI Gateway-budgetar.
Skala först därefter upp provet till en månad: multiplicera kostnaden per lyckat normalbygge med ett realistiskt antal byggen och lägg till den observerade andelen tunga byggen. Visa ett intervall om antalet deployer varierar. Ta med utvecklartid eller väntetid som en separat verksamhetskostnad om den spelar roll för teamet; göm den inte i Vercels minutpris.
5. Besluta med en gräns och öva återställningen
Sätt kriterierna innan tabellen summeras. Ett rimligt protokoll kan kräva noll resursfel i de tunga körningarna, en maximal byggtid som håller teamets CI-mål och en minsta nettobesparing efter omkörningar. Procentsatsen och tidsgränsen är teamets beslut, inte Vercels löften. Lägg dessutom in ett stoppvillkor: två minnes- eller timeoutfel, eller ett bygge som passerar releasefönstrets hårda gräns, återställer Elastic omedelbart.
Om Basic godkänns, gör bytet först i benchmarkprojektet eller en avgränsad previewmiljö och följ de kommande tio representativa byggena. Om utfallet glider utanför gränsen återställer du den sparade Elastic-inställningen och kör samma commit en gång kall och en gång varm. Det bevisar att vägen tillbaka fungerar. För ett mer generellt upplägg kring låsta indata och jämförbara körningar kan du återanvända principerna i guiden till reproducerbara körningar.
Källor
- Vercel Changelog: Basic build machines are now available on Pro and Enterprise – lanseringsdatum, tillgänglighet, resurser, standardval, CLI-version och Basic-kommandot
- Vercel Docs: Managing Builds – maskinstorlekar, Elastic-tilldelning, behörighet och debitering per CPU-minut
- Vercel Docs: Builds – byggflöde, köer, loggar och Build Diagnostics
- Vercel Docs: Pricing – aktuella byggpriser, avrundning, enheter och skatteavgränsning
- Vercel Docs: Troubleshooting Build Errors – Redeploy utan befintlig build cache och dokumenterade resursfel
Uppgifterna kontrollerades mot Vercels primärkällor den 4 september 2026. Maskinstorlekar, priser, CLI och gränssnitt kan ändras; kontrollera aktuell dokumentation och faktura innan ett skarpt beslut.