Vercel

Kurz: Eine Hosting-Plattform, die auf Next.js-Projekte (und andere Frontend-Frameworks) spezialisiert ist — jeder git push kann automatisch einen neuen Deploy auslösen.

Genauer: Projekte gehören zu einem “Team” oder dem persönlichen Account; jedes Projekt hat eigene Environment Variables, Domains und Storage-Anbindungen (z. B. Vercel Blob). Die CLI (vercel) kann parallel zum automatischen Git-Deploy manuell deployen (vercel --prod) — nützlich, wenn z. B. der Git-Commit-Autor beim automatischen Deploy blockiert wird.

Kontext bei uns: Zentrale Hosting-Plattform für Emzett — eigener Account/Team eingerichtet, losgelöst vom alten Bellator-Vercel-Account des ehemaligen Partners.

Im Detail

Production- und Preview-Deployments

Jeder Push auf den konfigurierten Produktions-Branch (meist main) löst automatisch einen Production-Deploy aus; Pushes auf andere Branches oder Pull Requests erzeugen dagegen automatisch eigene Preview-Deployments — jeweils eine vollständig eigenständige, unter einer eigenen URL erreichbare Version der App, isoliert von der Produktion. Das erlaubt, eine Änderung live zu testen (inklusive echter Server-Funktionalität, nicht nur statischem HTML), bevor sie überhaupt gemerged wird. Jedes Preview-Deployment kann zudem eigene Environment Variables haben — z. B. eine Test-Datenbank statt der echten Produktionsdatenbank —, sodass Experimente in Preview-Umgebungen risikofrei gegenüber echten Nutzerdaten bleiben.

Serverless vs. Edge Functions

Next.js-Projekte laufen auf Vercel standardmäßig über eine Mischung aus statisch vorgerenderten Seiten (dort, wo möglich, z. B. Seiten ohne nutzerspezifische Inhalte) und Serverless/Edge Functions für alles, was dynamisch pro Request berechnet werden muss (API-Routes, Server Components mit Datenbankzugriff). Der Unterschied zwischen den beiden Function-Typen: Serverless Functions laufen in einer vollständigen Node.js-Umgebung (mehr Kompatibilität, aber langsamerer Kaltstart), Edge Functions in einer schlankeren, näher am Nutzer verteilten Laufzeitumgebung (schnellerer Kaltstart, aber eingeschränktere Node.js-API-Unterstützung) — welcher Typ verwendet wird, lässt sich pro Route über export const runtime = "edge" steuern. Der “Kaltstart” bezeichnet dabei die Zeit, bis eine Funktion, die gerade nicht aktiv läuft, für einen neuen Request bereit ist — bei geringem Traffic (Funktion wird selten aufgerufen) macht sich dieser Unterschied deutlicher bemerkbar als bei konstant hoher Auslastung, wo Funktionen ohnehin meist “warm” bleiben.

Edge-Netzwerk und CDN

Statische Inhalte (vorgerenderte Seiten, Bilder, CSS/JS-Bundles) werden automatisch über ein globales CDN (Content Delivery Network) ausgeliefert — Vercel hält Kopien an vielen geografisch verteilten Standorten vor, sodass ein Nutzer die Inhalte vom jeweils nächstgelegenen Standort statt von einem einzelnen, potenziell weit entfernten Server bekommt. Das reduziert Ladezeiten spürbar, besonders für Nutzer, die geografisch weit vom ursprünglichen Serverstandort entfernt sind.

Build-Prozess und Zwischenspeicherung

Bei jedem Deploy führt Vercel den kompletten Next.js-Build-Prozess (next build) in einer isolierten Build-Umgebung aus — Abhängigkeiten werden dabei zwischen Builds zwischengespeichert (Cache für node_modules), um wiederholte Builds desselben Projekts zu beschleunigen. Schlägt ein Build fehl (z. B. durch einen TypeScript-Fehler oder eine fehlende Environment Variable), bleibt die vorherige, funktionierende Production-Version unverändert live — ein fehlgeschlagener Deploy legt die App also nicht automatisch lahm, sondern wird schlicht verworfen.

Domains und DNS

Vercel-Projekte bekommen automatisch eine *.vercel.app-Subdomain, eigene Domains lassen sich zusätzlich über DNS-Einträge (meist A- oder CNAME-Records) verbinden. Für den Produktionsbetrieb ist eine eigene Domain praktisch immer sinnvoller als die automatisch generierte Vercel-Subdomain, schon aus Gründen der Wiedererkennbarkeit und Unabhängigkeit von der Hosting-Plattform.

Siehe auch: Environment Variables, Vercel Blob Storage, DNS-Records