Vercel ist für Next.js-Anwendungen der Weg mit der geringsten Reibung: Repository verbinden, pushen, live. Für ein einzelnes Projekt reicht das. Wer mehrere Produkte betreibt, Kundendaten verarbeitet und Releases ohne Überraschungen will, braucht ein paar bewusste Entscheidungen mehr. Wir betreiben unsere Produkte und diese Website auf Vercel; dieser Beitrag beschreibt die Muster, die sich dabei bewährt haben.
Ein Projekt pro Produkt
Jedes Produkt bekommt ein eigenes Vercel-Projekt mit eigener Domain, eigenen Umgebungsvariablen und eigenem Release-Rhythmus. Gemeinsame Bausteine — Komponenten, Hilfsfunktionen, Konfiguration — leben in geteilten Paketen, nicht in Kopien. So bleibt ein Fehler in einem Produkt auf dieses beschränkt, und Zugriffsrechte lassen sich pro Produkt vergeben. Für kommerzielle Produkte gehört das Projekt in ein Team auf einem kostenpflichtigen Plan; der kostenlose Hobby-Plan ist nicht für kommerzielle Nutzung gedacht.
Drei Umgebungen, getrennte Daten
Vercel unterscheidet Production, Preview und Development, und Umgebungsvariablen lassen sich pro Umgebung setzen. Das wichtigste Muster ist die Trennung der Daten: Previews verbinden sich mit einer eigenen Datenbank oder einem eigenen Supabase-Projekt, nie mit der Produktion. Sonst testet ein Pull Request mit echten Kundendaten, und ein fehlerhafter Migrationsschritt in einer Preview trifft die Produktion. Schlüssel mit erhöhten Rechten werden nur serverseitig verwendet und tragen nie das Präfix, das sie im Browser sichtbar macht.
Die Funktionsregion bewusst setzen
Serverfunktionen laufen bei Vercel ohne Konfiguration in einer US-Region. Für Produkte mit Daten in der EU oder der Schweiz sollte die Region nahe an der Datenbank liegen, etwa in Frankfurt. Das ist zugleich eine Datenschutz- und eine Performancefrage: Jede Datenbankabfrage aus der falschen Region kostet Latenz, und Verarbeitung in den USA ist eine Bekanntgabe ins Ausland, die man begründen muss. Statische Seiten aus dem CDN sind davon nicht betroffen; deshalb lohnt sich statische Generierung doppelt. Mehr zur Standortfrage in der Entscheidungshilfe Schweizer Hosting oder EU-Hosting.
Previews als Prüfstand
Jeder Push und jeder Pull Request erzeugt eine Preview mit eigener URL. Das ist der beste Ort, um Änderungen fachlich zu prüfen, bevor sie live gehen. Zwei Dinge gehören dazu: Previews mit echten oder realistischen Daten sollten mit dem Zugriffsschutz von Vercel geschützt sein, und Previews sollen nicht in Suchmaschinen landen. Vercel kennzeichnet Preview-URLs standardmässig für Suchmaschinen als nicht indexierbar; der Zugriffsschutz ist trotzdem sinnvoll, wenn Inhalte nicht öffentlich sein sollen.
Prüfungen vor dem Release
Ein grüner Build ist nicht dasselbe wie ein korrektes Release. Für unsere Websites läuft vor jeder Auslieferung eine automatisierte Prüfung über den gebauten Output: Jede Sitemap-URL muss existieren, eine korrekte Canonical und gültige strukturierte Daten haben und intern verlinkt sein. Für Anwendungen gehören Tests, Typprüfung und ein automatisierter Test der Mandantentrennung dazu. Diese Schritte laufen in der CI/CD-Pipeline oder vor dem Upload, nicht nach dem Release.
Rollbacks und Migrationen
Vercel erlaubt, mit einem Klick auf ein früheres Deployment zurückzuschalten. Das ist ein starkes Sicherheitsnetz für Code, aber nicht für Daten: Eine Datenbankmigration, die mit dem neuen Code ausgeliefert wurde, wird durch einen Rollback nicht rückgängig gemacht. Bewährt hat sich, Migrationen rückwärtskompatibel zu gestalten — erst Spalten hinzufügen, Code umstellen, alte Spalten später entfernen — und riskante Funktionen hinter Feature Flags zu stellen, die sich ohne Deployment abschalten lassen.
Betrieb sichtbar machen
Logs, Fehlermeldungen und Performance gehören in eine Übersicht, die man nicht suchen muss. Vercel liefert Logs und Messwerte zur Ladezeit; für längere Aufbewahrung und Alarme lohnt sich eine Anbindung an ein eigenes Monitoring. Wichtig ist, dass Fehler sich melden, statt dass man sie findet — mehr dazu unter Observability. Felddaten zu den Core Web Vitals beschreibt der Beitrag Core Web Vitals auf Next.js und Vercel.
Die häufigsten Fehler
- Previews mit Zugriff auf die Produktionsdatenbank.
- Serverfunktionen in einer anderen Region als die Datenbank.
- Geheime Schlüssel mit dem Präfix für öffentliche Variablen.
- Rollback ohne Plan für bereits ausgeführte Migrationen.
- Kommerzielle Produkte auf einem privaten Plan.
Die Architektur dahinter beschreibt der Beitrag zum Next.js App Router in Produktion. Für neue Produkte richten wir dieses Setup im SaaS-Launch-Paket von Anfang an ein.