Ich versuche gerade, eine Next.js-Anwendung auf Vercel zu deployen und muss Umgebungsvariablen (API-Keys, URLs usw.) hinzufügen. Ich habe eine .env.local-Datei auf meinem Computer erstellt, die funktioniert, aber wenn ich zu GitHub pushe und Vercel den Build durchführt, kann die Anwendung nicht auf diese Variablen zugreifen. Wie bringe ich das sicher zu Vercel?
Die .env.local wird niemals in die Produktion gehen, weil Git sie standardmäßig ignoriert (sie steht in der .gitignore), daher hat Vercel keinen Zugriff auf diese Variablen, wenn das Deployment durchgeführt wird. Du musst die Variablen direkt im Vercel-Dashboard konfigurieren. Gehe zum Projekt im Vercel-Dashboard, dann zu Settings > Environment Variables und füge jede benötigte Variable hinzu - Name und Wert. Wenn du Variablen hast, die nur in der Entwicklung benötigt werden (wie lokale Tests), markiere das Kästchen "Development" nur für diese. Für die, die dein Next.js sowohl auf dem Server als auch auf dem Client braucht, füge sie ohne Umgebungsbeschränkungen hinzu.
Für Variablen, die nur auf dem Server bleiben sollen (wie sensitive API Keys), fügst du sie normal hinzu und nutzt sie im Code innerhalb von serverseitigen Funktionen - getServerSideProps, API Routes, Server Components. Next.js gibt diese automatisch nicht an den Browser weiter. Wenn du eine Variable auf dem Client zugreifen musst, stelle ihr NEXT_PUBLIC_ voran (z. B. NEXT_PUBLIC_API_URL) und sie ist dann im Browser verfügbar, aber nutze das nur für Daten, die nicht sensibel sind.
Nachdem du alles in Vercel konfiguriert hast, mache einen neuen Push zu GitHub, auch wenn du nichts geändert hast - Vercel wird einen Rebuild mit den Variablen durchführen, die du gesetzt hast. Wenn du Preview Deployments nutzt (automatisches Deployment von Pull Requests), konfiguriere die Variablen auch für diese Test-Umgebungen, indem du in den Settings zum Bereich "Preview" gehst. Tipp: Wenn du viele Variablen hast, kopiere einen kompletten Block von einer Umgebung zur anderen, anstatt sie einzeln hinzuzufügen.
Geh ins Vercel-Dashboard, öffne das Projekt, geh zu Settings > Environment Variables und füge dort die Keys ein, die du in deiner .env.local nutzt. Erstelle eine Variable für jede (API_URL, API_KEY, was immer du brauchst) und markiere, in welcher Umgebung jede funktioniert - Development, Preview, Production oder alle drei. Danach injiziert Vercel diese Variablen beim Build in den Prozess und die Anwendung kann auf sie über `process.env.NAME_DER_VARIABLEN` zugreifen.
Jetzt, der Punkt den viele übersehen: Wenn du Variablen nutzt, die nur auf dem Server zugänglich sein können (wie Datenbankpasswörter oder geheime API Keys), musst du nur diejenigen mit `NEXT_PUBLIC_` prefixen, die zum Client-Side gehen. Alles ohne diesen Prefix bleibt beim Build sicher auf dem Server. Wenn du einen sensitiven Key mit `NEXT_PUBLIC_` hinzufügst, landet er im JavaScript das der Browser herunterlädt - dann ist es nicht mehr sicher. Also pass mit dieser Konvention auf, weil man leicht einen Fehler machen kann.
Ein nützlicher Tipp ist auch, die Struktur deiner .env.local in eine Datei namens .env.example (oder .env.local.example) zu kopieren, die echten Werte zu entfernen und das ins Git zu committen. So weiß jeder, der am Projekt arbeitet, genau welche Variablen er lokal und auch im Vercel konfigurieren muss.
Lass die sensiblen Schlüssel auf keinen Fall ins Repository, auch nicht "nur vorübergehend" - danach vergisst du es und sie werden geleakt. Die Leute dort haben den Weg über das Dashboard schon gut erklärt, aber es gibt einen wichtigen Detail: Wenn du Variablen hast, die im Browser verfügbar sein müssen (wie ein öffentlicher API-Schlüssel), musst du sie bei Vercel mit `NEXT_PUBLIC_` prefixen, sonst kommen sie nicht auf der Client-Seite an. Die, die nur auf dem Server bleiben sollen (wie Datenbank-Credentials), lässt du ohne Prefix und sie laufen nur auf dem Server - du kannst sie nur in getServerSideProps, API Routes usw. aufrufen. Das verhindert, dass Daten, die nicht im Quellcode sichtbar sein sollten, offengelegt werden.
Leute haben das schon richtig erklärt, aber ich füge noch ein Detail hinzu: Neben dem Eintragen der Variablen im Dashboard musst du darauf achten, dass du die richtige Syntax in deinem Code verwendest - in Next.js sind Variablen, die mit `NEXT_PUBLIC_` beginnen, im Browser sichtbar (das ist z.B. für öffentliche URLs nützlich), während die anderen nur auf dem Server bleiben, was für sensible Keys wirklich wichtig ist.
Das habe ich auf die harte Tour gelernt, als ich versehentlich einen API-Key exposieren wollte und festgestellt habe, dass der Browser darauf zugreifen konnte, weil ich `NEXT_PUBLIC_` davor gesetzt hatte. Jetzt überprüfe ich immer doppelt, wofür die Variable eigentlich gedacht ist, bevor ich sie konfiguriere.
Anmeldenzum Beantworten.
