Vercel: Mein Lieblingshoster für TypeScript-Projekte

Hosting ist eigentlich eines dieser Themen, über die ich nicht gerne nachdenke.

Nicht, weil es unwichtig ist.

Eher im Gegenteil.

Wenn Hosting nervt, nervt plötzlich alles: Deployments, Previews, Environment Variables, Domains, Logs, Builds, Edge-Cases, Rollbacks und diese eine Kleinigkeit, die freitags um 16:47 Uhr natürlich nicht einfach funktionieren möchte.

Deshalb mag ich Vercel so sehr.

Für mich ist Vercel privat und auf der Arbeit der Hoster, bei dem TypeScript-Projekte am schnellsten von „lokal läuft es“ zu „online ist es“ kommen, ohne dass daraus direkt ein Infrastruktur-Hobby wird.

Warum gerade TypeScript so gut passt

Ich baue fast alles, was Web ist, irgendwie in TypeScript.

Nuxt, kleine interne Tools, Landingpages, APIs, Admin-Oberflächen, Experimente, Prototypen. Manchmal sauber geplant, manchmal ehrlich gesagt eher: Ich will mal schnell sehen, ob diese Idee trägt.

Vercel passt zu genau diesem Spektrum.

Ein Git-Repository verbinden, Framework erkennen lassen, Environment Variables setzen, Preview Deployments bekommen, Domain drauf, fertig. Natürlich ist in echten Projekten nie alles nur so simpel. Aber der Einstieg fühlt sich sehr oft so an.

Und das ist viel wert.

Gerade bei TypeScript-Projekten will ich nicht zuerst einen Server streicheln, Build-Pfade erklären und Deployment-YAML meditieren. Ich will pushen und sehen, ob die App funktioniert.

Preview Deployments sind Alltagsschutz

Das stärkste Vercel-Feature ist für mich nicht das spektakulärste.

Es sind Preview Deployments.

Jeder Branch, jeder Pull Request, jede Änderung kann als echte URL existieren. Nicht als „stell dir vor, das wäre online“, sondern als tatsächlich klickbares Ding.

Auf der Arbeit ist das Gold wert.

Man kann Features zeigen, bevor sie gemerged sind. Man kann Feedback an einer echten Oberfläche sammeln. Man kann Dinge testen, ohne lokal bei jedem Beteiligten das gleiche Setup zu erklären.

Privat ist es genauso angenehm.

Gerade bei Projekten wie dieser Seite will ich sehen, wie ein Artikel, ein Bild oder ein Layout wirklich deployed aussieht. Lokal und mit gutem Gefühl reicht mir da nicht, ich will es im echten Hosting-Kontext sehen.

Vercel nimmt mir die langweiligen Teile ab

Vercel macht vieles, was ich nicht jedes Mal neu entscheiden will.

Builds, Caching, CDN, Framework-Optimierungen, Serverless Functions, Routing Middleware, Environment Variables, Domains und SSL.

Das sind keine kleinen Dinge.

Aber Vercel schafft es, dass sie sich im Alltag oft klein anfühlen.

Wenn ich eine Nuxt- oder Next-App deploye, muss ich nicht bei null anfangen. Vercel erkennt viel automatisch und setzt die üblichen Teile so zusammen, dass ich erstmal arbeiten kann.

Man kann über Details streiten. Es gibt Limits, Kostenfragen und Fälle, in denen man lieber eine eigene Infrastruktur oder einen anderen Anbieter nimmt.

Aber mein Default ist trotzdem: Wenn es TypeScript im Web ist, denke ich zuerst an Vercel.

Was ich daran mag

• Git Push fühlt sich nah an Produktion an. Ein ziemlich direkter Weg statt zehn Zwischenschritten.
• Preview URLs sind unfassbar praktisch. Für Arbeit, Feedback, Kunden, Kollegen und eigene Kontrolle.
• Framework-Support ist stark. Next ist naheliegend, aber auch Nuxt und andere moderne Setups fühlen sich dort zuhause an.
• Serverless Functions reichen oft völlig. Kleine APIs, Webhooks, Backend-Logik und Integrationen müssen nicht sofort ein eigenes Serverprojekt werden.
• Domains und SSL sind angenehm unspektakulär. Genau so sollte es sein.
• Logs und Deployments sind schnell erreichbar. Wenn etwas kaputt ist, will ich nicht erst eine Infra-Schatzkarte lesen.

Und vielleicht ist das der Kern: Vercel fühlt sich nicht wie eine separate Hosting-Welt an.

Es hängt direkt an der Art, wie ich ohnehin arbeite.

Code ändern, pushen, ansehen, verbessern.

Die Grenzen sind trotzdem echt

Ich will Vercel nicht romantisieren.

Wenn ein Projekt sehr spezielle Infrastruktur braucht, lange laufende Prozesse, ungewöhnliche Runtime-Anforderungen oder volle Kostenkontrolle auf jeder Ebene, dann ist Vercel nicht automatisch die beste Antwort.

Vor allem wenn man aus der „alten Welt“ der Webentwicklung kommt, wo man eine virtuelle Maschine mit Festplatte und gesamtem Betriebssystem zur Verfügung hat, wird man an der ein oder anderen Stelle in der Serverless-Welt erst einmal blöd gucken.

Einfach eine Datei im Formular hochladen? Einfach mal eine E-Mail verschicken?

Ja, technisch gehen diese Dinge auf dem „alten Weg“ alle irgendwie, aber nicht vernünftig und erst recht nicht lange gut.

Schnell kommen dann Dienste wie Vercel Blob, S3 oder Postmark ins Spiel, weil sie echt Probleme lösen, von denen man vorher vielleicht nicht mal wusste, dass man sie hatte.

Aber das ändert nichts daran, dass Vercel für sehr viele TypeScript-Webprojekte genau richtig ist.

Das heißt nicht, dass alles egal ist. Die normalen Dinge sind einfach normal gelöst.

Warum ich immer wieder dort lande

Ich nutze Vercel privat, weil es meine kleinen Projekte schneller aus dem Kopf ins Netz bringt.

Ich nutze Vercel auf der Arbeit, weil Preview Deployments, saubere Integrationen und schnelle Iteration echten Teamalltag leichter machen.

Und ich mag Vercel, weil es Hosting an vielen Tagen wieder zu dem macht, was es für mich sein sollte: eine Infrastruktur im Hintergrund, keine Nebenkarriere.

Wenn ich an einer Idee arbeite, möchte ich über Produkt, Text, UI, Daten und Nutzer nachdenken.

Nicht über den 14. YAML-Block.

Würde ich Vercel empfehlen?

Ja.

Für TypeScript-Webprojekte ist Vercel mein Default.

Es passt nicht auf jede Architektur und nicht auf jedes System, aber auf sehr viele Projekte, bei denen schnell, sauber und wiederholbar deployt werden soll.

Vercel ist für mich gutes Zeug, weil es Deployment aus dem Weg räumt, ohne sich dabei wie ein billiger Shortcut anzufühlen.

Es ist ein Hoster, der meine Arbeitsweise versteht.

Und das ist seltener, als es sein müsste.