Es war Donnerstagabend und die Next.js-Website eines Kunden war gerade in das, was ich nur als Timeout-Spirale beschreiben kann, abgerutscht. Serverless Functions, die bei 9,8 Sekunden hängen blieben, Nutzer mit leeren Bildschirmen, und ich, der um Mitternacht fieberhaft das Vercel Dashboard überprüfte, um herauszufinden, ob wir wirklich ein Plan-Limit erreicht hatten oder ob der Code einfach nur furchtbar war. (Es war beides, ehrlich gesagt.) Das Projekt war im Hobby-Plan. Hätte es wahrscheinlich nicht sein sollen.
Ich habe über die Jahre mehr als 12.000 Websites bei Seahawk Media deployed. Vercel ist ständig Teil unseres Stacks, besonders bei Next.js-Arbeiten – nichts anderes kommt in der Developer Experience auch nur annähernd heran. Aber der Hobby-Plan hat scharfe Kanten, die man leicht übersieht, bis ein Projekt dich beißt. Also hier ist meine ehrliche Einschätzung, wo diese Kanten sind und wann sie anfangen zu zählen.
Was der Hobby-Plan dir wirklich gibt
Seien wir präzise. Stand 2024 gibt dir Vercels Hobby-Plan:
100 GB Bandbreite pro Monat
6.000 Build-Minuten pro Monat
Serverless-Funktions-Ausführungs-Timeout von 10 Sekunden
100 Serverless-Funktionsaufrufe pro Tag... moment, nein. Dieses Limit gibt es nicht. Aber es gibt eine Obergrenze von 100 GB-Stunden Serverless-Funktionsausführung pro Monat
Edge-Funktionsausführung von 500.000 Aufrufen pro Monat
1 gleichzeitiger Build auf einmal
Deployments beschränkt auf persönliche Konten (keine Teams)
Kommerzielle Nutzung nicht erlaubt gemäß Vercel-Bedingungen
Dieses letzte Limit verwirrt die Leute mehr als jedes technische Limit. Der Hobby-Plan ist explizit für persönliche, nicht-kommerzielle Projekte. Falls du für einen zahlenden Kunden baust oder irgendein Geschäft darauf betreibst, verstößt du bereits gegen die Nutzungsbedingungen. Ich habe Freelancer jahrelang das machen sehen und es ist eine Haftung, die nur auf einen Vorfall wartet.
Das 10-Sekunden-Funktions-Timeout
Das ist das, das die Leute trifft. Zehn Sekunden klingt nach viel, bis du einen API-Aufruf eines Drittanbieters machst, der 4 Sekunden dauert, eine Datenbanklogik ausführst, die weitere 3 hinzufügt, und dann etwas mit der Antwort machst. Plötzlich bist du bei 9,2 Sekunden ohne Spielraum.
Im Pro-Plan springt diese Grenze auf 60 Sekunden (und bis zu 900 Sekunden mit Konfiguration bei Enterprise). Das ist kein marginaler Unterschied. Das ist der Unterschied zwischen einer funktionierenden Integration und einem Produkt, das für bestimmte Use Cases grundlegend kaputt ist.
Build Minutes: Wo sie schneller verschwinden, als man denkt
6.000 Build Minutes pro Monat klingt großzügig. Und für ein einzelnes persönliches Projekt ist es das wahrscheinlich auch. Das Problem ist, dass diese Zahl schneller schrumpft als erwartet, sobald du ernsthaft iterierst.
2021 habe ich an einem Nebenprojekt gearbeitet, einem Content Aggregator auf Next.js-Basis mit etwa 400 statischen Seiten. Ich hatte ISR eingerichtet, machte aber auch häufig vollständige Rebuilds während ich mit der Datenschicht experimentierte. In drei Wochen habe ich ungefähr 4.200 Build Minutes verbraucht. Nicht weil die Builds langsam waren, sondern weil ich sie ständig ausgelöst habe.
Ein Build auf einer mittelkomplexen Next.js-Site kann problemlos 4–8 Minuten dauern. Wenn du während aktiver Entwicklung 15-mal am Tag auf main pushst (was für mich normal ist), sind das 60–120 Build Minutes weg an einem einzigen Tag. Mach das eine Woche lang und du hast die Hälfte deines monatlichen Kontingents aufgebraucht.
Es gibt keinen Rollover. Minutes werden nicht von Monat zu Monat übertragen. Und wenn du bei null angekommen bist, stoppen deine Deployments. Punkt.
Wie man den Verbrauch bremst
Ein paar Dinge, die ich bei Hobby-Plan-Projekten mache, um Build Minutes zu sparen:
Pushe experimentelle Änderungen in einen Non-Production-Branch. Merge zu main nur, wenn etwas wirklich ready ist.
Nutze vercel --prebuilt mit gecachten Outputs, wo sich die Build-Artefakte nicht wesentlich geändert haben.
Konfiguriere Vercels ignorierten Build-Schritt so, dass Builds übersprungen werden, wenn sich nur bestimmte Dateien ändern (wie Readme-Updates oder Commits ohne Code-Änderungen).
Commits zusammenfassen. Anstatt 6 kleine Fixes einzeln zu pushen, stagen sie und pushen sie auf einmal.
Das ist nichts Neues. Aber in der Praxis pushen die meisten Entwickler auf Hobby-Plänen einfach munter drauflos und wundern sich, warum ihnen die Minuten am 20. des Monats ausgegangen sind.
Bandbreite: Meistens okay, manchmal nicht
100 GB Bandbreite pro Monat ist der Punkt, an dem der Hobby-Plan eigentlich ziemlich großzügig ist. Für ein persönliches Projekt, ein Portfolio, einen kleinen Blog, sogar ein bescheidenes SaaS-Nebenprojekt mit ein paar hundert Nutzern, wirst du dieses Limit wahrscheinlich nicht erreichen.
Problematisch wird es bei bilderlastigen Seiten ohne ordentliche CDN-Schicht davor oder bei Seiten, die einen plötzlichen Ansturm bekommen. Ich hatte einen Kunden, einen Musiker, dessen Seite während einer Übergansphase auf meinem persönlichen Vercel-Account lag (das war falsch von mir, ich weiß, kommerzielle Nutzung und so weiter). Einer seiner Tracks wurde von einer einigermaßen großen Playlist aufgegriffen und die Seite bekam etwa 40.000 Besuche in 48 Stunden. Die Bandbreitennutzung schoss in die Höhe. Zum Glück waren wir unter dem Limit, aber es war knapp genug, dass ich sie sofort von Hobby runtergezogen habe.
Wenn du Next.js Image Optimisation nutzt, beachte, dass optimierte Bilder, die über Vercel ausgeliefert werden, auf deine Bandbreite angerechnet werden. Und der Hobby-Plan hat eine Obergrenze von 1.000 Quellbildern pro Monat für die Optimierung. Das ist ein Limit, über das fast niemand spricht, und es wird dich absolut treffen, wenn du ein Fotografie-Portfolio betreibst oder eine bilderlastige Content-Seite.
Die Sache mit der kommerziellen Nutzung verdient mehr Aufmerksamkeit
Ich möchte darauf zurückkommen, weil ich denke, dass das in Freelancer-Kreisen wirklich unterschätzt wird.