Vercel Hobby: Alte Deployments können vor Ablauf von 30 Tagen verschwinden

Seit dem 16. September 2026 ist die 30-tägige Deployment-Historie von Vercel Hobby kein verlässliches Rollback-Versprechen mehr. Überschreitet ein Hobby-Team das Limit von 10GB Deployment Storage, kann ein altes Preview oder ein Produktions-Deployment als Rollback-Ziel sofort entfernt werden, sofern keine Ausnahme der Aufbewahrungsregeln greift.

Das aktuelle Produktions-Deployment bleibt geschützt. Das gilt auch für Deployments mit qualifizierenden Aliasnamen sowie für das neueste Preview eines aktiven Git-Branches. Betroffen ist alles außerhalb dieser geschützten Gruppen. Deshalb kann ein persönlicher Prototyp weiterlaufen, während ein älterer Review-Link unbemerkt sein Ziel verliert.

Warum die 30-Tage-Frist keine Untergrenze mehr ist

Die Deployment-Aufbewahrung legt fest, wie lange Vercel die erzeugten Dateien eines Deployments vorhält. Erst diese gespeicherten Dateien machen es möglich, ein altes Preview erneut aufzurufen, einen geprüften Build ohne erneuten Build in die Produktion zu übernehmen oder die Produktion bei einem Zwischenfall zurückzusetzen.

Für Hobby gilt regulär weiterhin eine Aufbewahrungsfrist von 30 Tagen. Neu ist die Bereinigung bei überschrittenem Limit: Sobald das Team mehr als 10GB Deployment Storage belegt, kann ein ungeschütztes Deployment schon vor Ablauf dieser 30 Tage zur Löschung freigegeben werden. Genau darin liegt die praktische Konsequenz der Änderung. Der kostenlose Deployment-Verlauf hängt nun sowohl vom Speicherverbrauch als auch von den folgenden Ausnahmen ab.

Jedes Hobby-Projekt erhält zwei Schutzregeln für aktuelle Deployments:

• Die neuesten 3 erstellten Deployments, unabhängig vom Typ
• Die neuesten 3 produktionsbereiten Deployments mit dem Status Ready

Diese Regeln bilden eine gemeinsame Menge und keine sechs reservierten Plätze. Ein aktuelles Produktions-Deployment kann zu beiden Gruppen gehören. Sind die drei neuesten Deployments zugleich die drei neuesten Ready-Produktions-Deployments, schützen diese beiden Regeln nur dieselben drei Deployments.

Für Preview-Deployments gibt es kein eigenes Kontingent aktueller Previews mehr. Ein Preview außerhalb der neuesten drei bleibt nur erhalten, wenn eine andere Ausnahme greift.

Welche Deployments Vercel Hobby weiterhin schützt

Am klarsten wird die Regel, wenn zeitabhängige Schutzmechanismen von solchen getrennt werden, die sich aus der Nutzung eines Deployments ergeben.

Diese Ausnahmen stehen in den aktuellen Regeln von Vercel zur Deployment-Aufbewahrung. Eine gespeicherte Deployment-URL allein gehört nicht zu den aufgeführten Schutzmechanismen. Entscheidend ist, ob das Deployment über einen Alias, einen Branch, seinen Produktionsstatus oder seine Position unter den neuesten Deployments geschützt wird.

Das verändert einen verbreiteten Arbeitsablauf. Ein Preview-Link wird geteilt, der Pull Request zusammengeführt und der Link für den Rest des Monats als verfügbar betrachtet. Sobald der Branch nicht mehr aktiv ist, endet jedoch die Ausnahme für sein neuestes Preview. Liegt das Team bereits über 10GB und gehört das Deployment zu keiner der beiden Gruppen der neuesten drei, kann der Link sein Ziel vor Tag 30 verlieren.

Wen die Änderung tatsächlich betrifft

Ein Solo-Entwickler mit mehreren persönlichen Prototypen ist das deutlichste Beispiel. Alte Projekte können gespeicherte Build-Ausgaben belegen, während aktive Projekte laufend neue Deployments erzeugen. Überschreitet das Team sein Limit, darf Vercel ungeschützte Historie im gesamten Hobby-Team bereinigen. Das wichtige Rollback-Ziel kann also zu einem Projekt gehören, das schon länger nicht mehr angefasst wurde.

Für Designer, die ein nicht kommerzielles Konzept teilen, liegt das Risiko an anderer Stelle. Das aktuelle Preview eines offenen Review-Branches ist geschützt, der ältere Link zu einer früheren Designentscheidung möglicherweise nicht. Muss genau dieser Build weiterhin prüfbar bleiben, braucht er vor dem Schließen des Branches einen qualifizierenden benutzerdefinierten Alias oder eine andere Sicherungsstrategie.

Wer Deployments als Rollback-Archiv nutzt, sollte die aktuellen Produktions-Deployments prüfen. Die neuesten 3 Ready-Produktions-Deployments bleiben geschützt. Eine ältere, nachweislich funktionierende Version ist jedoch nicht allein deshalb sicher, weil sie jünger als 30 Tage ist.

Freelancer, Agenturen und Unternehmen sollten die Aufbewahrung nicht als einziges Kriterium für ein Upgrade betrachten. Hobby ist auf persönliche, nicht kommerzielle Nutzung beschränkt. Kommerzielle Projekte gehören zu Pro, selbst wenn sie unter 10GB bleiben. Die Änderung am Deployment-Verlauf unterstreicht damit eine bereits bestehende Tarifentscheidung.

Hobby-Teams unter 10GB fallen nicht unter die neue Sofortbereinigung. Für ihre Deployments gelten weiterhin die reguläre 30-Tage-Regel und deren Ausnahmen. Auch Pro- und Enterprise-Teams sind von dieser konkreten Hobby-Änderung nicht betroffen. Dort sind sowohl die standardmäßigen Aufbewahrungsfristen als auch die geschützten Kontingente aktueller Deployments größer.

Relevante Deployment-Historie systematisch prüfen

Die Prüfung beginnt am besten auf Teamebene. Das Limit von 10GB gilt für das Hobby-Team, während die entscheidenden Hinweise auf mehrere Projekte verteilt sind.

1. 1

   Beide Speicheranzeigen prüfen

   In Vercel das richtige Team auswählen, Usage öffnen und anschließend Deployment Storage aufrufen. Zu prüfen sind sowohl Deployment Storage für Build-Ausgaben und statische Assets als auch Functions Storage für Function Bundles. Unter jeder Kennzahl zeigt Projects, welche Projekte den meisten gespeicherten Output verursachen.

2. 2

   Unverzichtbare Deployments festhalten

   Für jedes große Projekt Deployments öffnen. Zu dokumentieren sind das aktuelle Produktions-Deployment, der Produktions-Build für ein tatsächliches Rollback, alle Preview-URLs in laufenden Review- oder Freigabeprozessen sowie ältere Builds, die für Audits oder Regressionstests benötigt werden. Diese Liste definiert den Bedarf. Der Deployment-Feed ist lediglich das Inventar.

3. 3

   Jedes wichtige Deployment einem Schutzmechanismus zuordnen

   Für jeden Eintrag prüfen, ob er zu den neuesten 3 erstellten Deployments oder zu den neuesten 3 Ready-Produktions-Deployments gehört, einen qualifizierenden Alias trägt oder das neueste Preview eines aktiven Branches ist. Taucht dasselbe Deployment in beiden Gruppen der neuesten drei auf, darf es nicht doppelt gezählt werden.

4. 4

   Ausnahme oder Quellstand bewahren

   Ein Review-Branch sollte aktiv bleiben, solange sein neuestes Preview noch gebraucht wird. Ein unverzichtbares, nicht produktives Deployment kann einen benutzerdefinierten Alias erhalten, wenn das zum Arbeitsablauf passt. In allen anderen Fällen müssen Quell-Commit, Konfiguration und externe Daten für einen Neuaufbau außerhalb der Deployment-Historie verfügbar sein.

5. 5

   Speicher ohne Aufgabe abbauen

   Nachdem die Verantwortlichen entbehrliche Inhalte bestätigt haben, lassen sich veraltete benutzerdefinierte Aliasnamen entfernen und überholte Pull Requests im üblichen Repository-Prozess schließen. Anschließend zeigt die Ansicht Resources des größten Deployments, ob überdimensionierte statische Ausgaben oder Function Bundles vorliegen. Die Usage-Seite benennt zwar das Projekt, aber nicht die konkrete Datei, das Deployment oder das Bundle hinter dem Gesamtwert.

Der Leitfaden von Vercel zur Speicheroptimierung empfiehlt, nach einer Änderung dasselbe Team, beide Speicherkennzahlen, dieselben Projekte und denselben 30-Tage-Zeitraum zu vergleichen. Die Bereinigung der Aufbewahrung und kleinere Build-Ausgaben lösen unterschiedliche Probleme: Erstere reduziert mit der Zeit die gespeicherte Historie, Letztere verkleinert neue Deployments.

Bereinigung und Pro verändern unterschiedliche Kostenblöcke

Für ein persönliches, nicht kommerzielles Projekt ist die Bereinigung die Option ohne Abonnementkosten. Nicht mehr benötigte Historie wird aufgegeben, die Ausgabegröße soweit möglich reduziert und die Nutzung unter dem Hobby-Limit gehalten. Der Preis dafür ist operativer Natur: Es stehen weniger alte Previews zur Prüfung und weniger Produktions-Builds für Rollbacks bereit.

Pro ist kein Upgrade für $0.10. Deployment Storage und Functions Storage kosten bei Pro jeweils $0.10 pro GB-Monat; 10GB einer dieser Kennzahlen für einen vollen Monat werden daher mit $1 ausgewiesen. Der Tarif beginnt jedoch mit einer monatlichen Plattformgebühr von $20. Darin enthalten sind ein Nutzerplatz mit Deployment-Rechten und ein monatliches Guthaben von $20 für die Infrastrukturnutzung. Jeder weitere Owner- oder Member-Nutzerplatz mit Deployment-Rechten kostet zusätzlich $20 pro Monat. Viewer-Nutzerplätze sind kostenlos.

Damit ist die Entscheidungsregel klar: Nicht „Historie löschen“ mit „$1 für Speicher zahlen“ vergleichen, sondern die Bereinigung dem vollständigen Monatstarif von $20 gegenüberstellen. Danach kommen alle zusätzlichen Deployment-berechtigten Personen hinzu; außerdem ist zu prüfen, ob das enthaltene Guthaben den tatsächlichen Speicherverbrauch und die übrige Infrastrukturnutzung des Teams deckt. Die vollständige Aufschlüsselung der Vercel-Preise erläutert die restliche Rechnung.

Bei einem persönlichen Prototyp können $20 pro Monat mehr kosten, als die gesicherte Historie wert ist. Bei kommerzieller Arbeit beantwortet bereits die Tarifberechtigung die Frage, noch bevor die Aufbewahrung relevant wird. Für ein Unternehmen mit einem Entwickler, das Pro ohnehin benötigt, gehören die längeren standardmäßigen Aufbewahrungsfristen und der umfassendere Schutz aktueller Deployments zum bereits bezahlten Gegenwert.

Was am Montag zu tun ist

Liegt ein Hobby-Team über oder nahe an 10GB, beginnt die Prüfung auf der Usage-Seite: Zuerst die Projekte mit dem größten Anteil an Deployment Storage und Functions Storage ermitteln. Danach werden genau die Preview-Links und Rollback-Ziele markiert, die noch einen geschäftlichen Zweck oder eine Review-Aufgabe erfüllen. Diese Deployments sollten gezielt geschützt werden; Historie ohne Aufgabe kann entfallen.

Liegt das Team komfortabel unter 10GB, besteht kein Anlass für eine sofortige Bereinigung. Die reguläre 30-Tage-Regel bleibt dennoch wichtig, insbesondere wenn ein Branch geschlossen werden soll, dessen Preview noch jemand benötigt.

Bei einem kommerziellen Projekt ist die Hobby-Bereinigung keine langfristige Strategie. Einzuplanen ist die volle Pro-Gebühr. Deployment-Zugriff erhalten nur die Personen, die ihn brauchen; für alle anderen stehen kostenlose Viewer-Sitze bereit. Diese Rechnung gehört mit den Kosten verglichen, die durch den Neuaufbau eines fehlenden Review- oder Rollback-Prozesses entstehen.

Einmal pro Woche eine ebenso klare Einordnung: Newsletter abonnieren.