Vercel debiterar deployments – kontrollera kostnad och rollback

Vercel börjar debitera befintliga Pro-team för lagringen av deployments och tillhörande funktionspaket. Samtidigt får berörda team ett kortare lagringsfönster om de inte aktivt väljer något annat.

För dig som driver en produkt på Vercel är detta inte bara en förändring på fakturan. Hur länge en deployment sparas avgör också vilka preview-miljöer du kan öppna, hur långt bak du kan undersöka ett fel och om en tidigare produktionsversion fortfarande går att återställa direkt.

Det viktiga är därför inte att radera så mycket som möjligt. Du behöver välja en retention som passar hur produkten utvecklas, testas och återställs.

Vad Vercel ändrar

I Vercels ändringslogg, publicerad den 9 oktober 2026, meddelar bolaget att debitering för Deployment Storage och Functions Storage börjar gälla även befintliga Pro-team. Det exakta startdatumet kan skilja sig mellan team och ska enligt Vercel framgå av mejlet till teamets administratörer.

I samband med förändringen anger Vercel att lagringsfönstret för berörda team ändras till trettio dagar. Deployments som är äldre än så börjar raderas från den 23 oktober 2026, om teamet inte väljer bort ändringen i sina retention-inställningar innan dess. Inställningar som redan har ett lika kort eller kortare fönster påverkas inte.

Det finns alltså två separata förändringar att hantera:

• Lagringen blir en debiterad resurs. Kostnaden påverkas av hur mycket byggutdata och funktionskod som sparas och hur länge materialet ligger kvar.
• Äldre deployments kan försvinna tidigare. Det minskar lagringen men förkortar också historiken som går att använda för felsökning, jämförelser och rollback.

Vercel låter dig sätta olika retention för Pre-Production, Production, Canceled och Errored deployments. Det gör att du inte behöver använda samma regel överallt. En misslyckad byggning har sällan samma långsiktiga värde som en stabil produktionsversion.

Kontrollera även om förändringen görs på teamnivå eller projektnivå. En teampolicy kan bli standard för nya projekt och kan även appliceras på befintliga projekt. En projektpolicy gäller bara det valda projektet. Var därför försiktig med alternativ som skriver över inställningarna för hela teamet.

Vad Deployment Storage faktiskt innehåller

En deployment är mer än en rad i Vercels historik. När Vercel bygger din applikation skapas filer som plattformen behöver för att kunna visa och köra just den versionen.

Deployment Storage omfattar bland annat byggutdata och statiska filer. Det kan vara färdigbyggd JavaScript, CSS, bilder som paketerats med projektet och annat innehåll från byggprocessen.

Functions Storage omfattar de paket som används för Vercel Functions. Ett sådant paket kan innehålla din serverkod, beroenden och annan kod som behövs när en funktion körs. Om funktioner distribueras i flera regioner kan samma typ av utdata behöva lagras på flera platser.

Lagringen växer främst när:

• projektet skapar deployments ofta
• gamla deployments behålls länge
• byggutdata innehåller stora statiska filer
• funktionerna drar in stora beroenden
• automatisering skapar dubbla eller onödiga deployments
• flera projekt använder en generös retention utan att historiken faktiskt behövs

Det här ska inte blandas ihop med exempelvis Vercel Blob eller databasen i Supabase. Deployment Storage är knuten till den byggda versionen av applikationen. Blob-lagring används för filer som applikationen själv laddar upp och hanterar. Supabase lagrar i sin tur data och databasstruktur utanför Vercels deployment.

Skillnaden är viktig vid rollback. När du återställer en äldre deployment återställer du applikationsversionen som Vercel har sparat. Du återställer inte automatiskt Supabase-data, databasmigreringar, Stripe-konfiguration eller förändringar i andra externa tjänster.

En äldre frontend kan därför gå att aktivera samtidigt som databasen redan har en ny struktur. Resultatet kan bli nya fel i stället för en fungerande återställning. En sparad deployment är alltså en viktig del av återställningen, men inte en fullständig backup av hela produkten.

Lägre lagring kan ge långsammare återställning

Det finns en tydlig avvägning mellan kostnad och återställningsförmåga. Kort retention minskar mängden lagrat material. Lång retention ger fler versioner att undersöka och återgå till.

För produktionsmiljön bör frågan vara: Hur långt efter en release kan vi rimligen upptäcka ett allvarligt fel?

Vissa fel syns direkt. Andra visar sig först när en viss kundresa används, en betalning förnyas, ett schemalagt jobb körs eller en äldre användare öppnar en del av produkten. Om den senast fungerande deploymenten redan har raderats kan du inte längre göra en omedelbar rollback till den via Vercel.

Då behöver du i stället hitta rätt commit i Git, bygga om den och skapa en ny deployment. Det kan fungera, men det är inte samma sak som att aktivera ett redan byggt och tidigare testat resultat. Byggmiljön, beroenden eller externa tjänster kan ha förändrats sedan den gamla versionen skapades.

Vercel har en återställningsperiod för deployments som nyligen markerats för radering. De kan under den perioden visas under Recently Deleted i projektets säkerhetsinställningar. Se detta som ett skydd mot misstag, inte som din ordinarie rollback-rutin. Misslyckade deployments kan dessutom tas bort snabbare än framgångsrika byggen.

Retention kan också påverkas av undantag. En deployment kan exempelvis behållas om den fortfarande har ett aktivt alias eller är den senaste preview-versionen för en aktiv Git-gren. Sådana undantag är praktiska, men kan också göra att lagringen inte minskar som förväntat.

En rimlig strategi är ofta att:

• behålla produktionsversioner utifrån den period då fel normalt upptäcks
• ge preview-versioner tillräcklig tid för granskning och godkännande
• rensa avbrutna och felaktiga byggen tidigare
• dokumentera vilka externa system som måste hanteras vid rollback
• regelbundet kontrollera att en äldre version fortfarande är kompatibel med databasen

Preview-miljöer behöver en tydlig livscykel

Preview-deployments är en av Vercels mest användbara funktioner. De gör det möjligt att testa en gren eller pull request utan att påverka produktionen. I arbetsflöden med Lovable eller kodagenter kan mängden previews däremot växa snabbt, särskilt om varje ändring skickas till Git och utlöser en ny byggning.

En kortare retention innebär att gamla preview-länkar slutar fungera tidigare. Det kan påverka dig om länkarna används för designgranskning, kundintervjuer, extern kvalitetssäkring eller godkännanden som tar tid.

Bestäm därför vad en preview-länk betyder i ditt arbetsflöde. Är den tillfällig och knuten till en aktiv gren, eller ska den fungera som ett arkiv över ett beslut? Om en viss version måste kunna visas långt senare är en vanlig preview-deployment kanske fel plats att lagra den på.

Se också över vad som faktiskt hamnar i varje byggning. Vanliga orsaker till onödigt stora deployments är:

• videor, arkiv eller exporter som ligger direkt i projektet
• en output-katalog som inkluderar mer än den färdiga applikationen
• serverfunktioner som importerar ett helt bibliotek för en liten uppgift
• genererade filer som borde skapas vid behov
• uppladdat användarinnehåll som har lagts i källkoden

Stora filer som ändras oberoende av applikationen bör normalt ligga i en separat fil- eller objektlagring. Då behöver inte varje deployment bära med sig en ny kopia. Flytten måste dock göras med hänsyn till åtkomstkontroll, radering, backup och hur filerna levereras till användaren.

Kontrollera även om automatisering skapar fler deployments än avsett. Deploy hooks, Git-integrationer, CI-jobb och kodagenter kan överlappa. Om samma commit byggs flera gånger bör du hitta den dubbla utlösaren innan du försöker lösa problemet enbart genom kortare retention.

Kontrollera detta i Vercel

Börja med att välja rätt team i Vercel och öppna Usage. Gå sedan till Deployment Storage och granska både vanlig Deployment Storage och Functions Storage. Jämför projekten för att se vilka som står för den största delen av lagringen.

Usage-vyn visar vilket projekt du bör undersöka, men inte alltid exakt vilken fil eller funktion som orsakar användningen. Öppna därför en representativ deployment i projektet och gå vidare till Resources. Där kan du granska statiska filer, funktioner, paketstorlekar och regioner.

Använd denna checklista:

• Läs mejlet från Vercel och notera när debiteringen börjar för teamet.
• Kontrollera retention för Pre-Production, Production, Canceled och Errored deployments.
• Säkerställ att ingen teaminställning oavsiktligt skriver över projekt med särskilda behov.
• Identifiera vilka projekt som använder mest Deployment Storage.
• Kontrollera Functions Storage separat – den kan avvika från den vanliga deployment-lagringen.
• Leta efter stora statiska filer och onödigt stora funktionspaket.
• Kontrollera gamla preview-grenar, öppna pull requests och inaktuella alias.
• Leta efter dubbla byggningar från Git, deploy hooks, CI och kodagenter.
• Bestäm hur långt tillbaka en produktionsversion måste kunna återställas direkt.
• Dokumentera hur Supabase, Stripe och andra externa system hanteras vid rollback.
• Testa återställningsrutinen innan den behövs under ett skarpt fel.

Ändra helst en sak i taget. Börja med retention där det är tydligt att historiken inte behövs. Följ sedan användningen över en jämförbar period. Om lagringen fortfarande är hög kan du gå vidare till byggutdata och funktionspaket. Då vet du vilken förändring som faktiskt gav effekt.

Målet är inte den kortaste möjliga retentionen, utan en medveten policy där kostnaden står i proportion till värdet av snabb felsökning och återställning.

När du har kontroll på drift och återställning är nästa fråga hur produkten ska börja bära sig – läs vidare om vägen till betalande kunder.

---

Källa: Vercel changelog