vercel env vars erreichten Produktion nie nach dem Publish

Deine vercel env vars liefen auf localhost — und Produktion scheiterte beim ersten API-Call, weil process.env leer war.

Lokal fühlte sich alles fertig an. Supabase verbunden. Stripe lud die Testkarte. Login leitete korrekt. Push zu GitHub, Vercel baute grün, Live-URL lud eine Hülle. Anmelden klicken — nichts. Server-Routes 500. Konsole zeigt fehlende Keys. Die App auf dem Laptop und auf *.vercel.app sind nicht dasselbe Binary. Sie lesen aus unterschiedlichen Umgebungsquellen.

Vercel liest die .env aus dem Repo nicht, außer du hast sie committed — was du nicht solltest. Production-Builds nutzen Variablen aus Vercel-Projekteinstellungen oder CLI. Lovable kann Keys für die Vorschau setzen. Diese Verkabelung endet beim Publish, bis du jeden Namen und Wert in Vercel Production kopierst und redeployest.

Env verließ nie den Laptop

Hinter der Hälfte der „lokal ok, live kaputt“-Meldungen steckt das. Du legtest .env.local nach einem Tutorial an. Next.js oder Vite lud es automatisch. Die KI referenzierte Namen im Code: VITE_SUPABASE_URL, STRIPE_SECRET_KEY, OPENAI_API_KEY. Git push schloss die Datei per .gitignore aus — richtig für Sicherheit. Vercel bekam die Werte nie.

Was du auf der Live-URL siehst:

• undefined in Server-Logs für Namen, die lokal existieren
• Client-Bundles mit Leerstrings statt Keys
• Supabase-Client mit undefined URL initialisiert
• Stripe-Webhook-Verifikation scheitert — STRIPE_WEBHOOK_SECRET fehlt
• OAuth oder Magic Links brechen — Redirect-Helfer lesen unset Vars

Vercel → dein Projekt → Settings → Environment Variables. Jeden Namen suchen, den der Code referenziert. Liste leer oder nur Preview/Development — Production-Builds haben nichts zu injizieren.

Lovable-Nutzer treffen dieselbe Lücke aus anderem Winkel. Der Editor speichert Integrations-Keys für die Vorschau. GitHub und Vercel deployen Code, nicht die Lovable-Secret-Schublade. Namen und Werte manuell übertragen oder Vercel CLI nutzen.

Produktion vs lokal

Vercel hat drei Umgebungen: Production, Preview, Development. Pro Key können Werte differieren. Häufiger Fehler: Vars nur unter Preview, weil dort PRs getestet wurden. Production deployt von main — Keys fehlen weiter.

Lokale .env-Dateien splitten per Konvention. Next.js liest .env.local auf deiner Maschine. .env.production auf der Platte synct nicht automatisch zu Vercel. Das Hosting-Dashboard ist Source of Truth für Cloud-Builds.

Framework-Regeln differieren. Vite exponiert nur VITE_-Präfixe ans Browser-Bundle. Server-Secrets ohne Präfix bleiben in Next.js API-Routes auf dem Server — müssen trotzdem in Vercel für Production existieren. Secret im Client-Code wegen hastiger Vorschau leakt im Bundle. Nur in .env.local ohne Vercel-Eintrag lässt Production blind.

Vergleich:

• Lokal: liest .env, .env.local, Shell-Exports; Hot Reload
• Vercel Production: Dashboard-Vars für Production-Scope bei Build und Runtime für Serverless
• Vercel Preview: PR-Deployments; Preview-scoped Vars, nicht Production ohne Duplikat
• Lovable-Vorschau: Editor-injizierte Keys; getrennt von Vercel ohne Kopie

Nach jeder Änderung frisches Production-Deployment. Vercel backt Client-Env beim Build ein. Variable editieren ohne Redeploy lässt altes Bundle auf dem CDN.

Warum KI annimmt, .env überall existiert

Coding-Agenten generieren process.env.NEXT_PUBLIC_SUPABASE_URL und gehen weiter. Sie sehen deine lokale Datei beim Dev-Run. Sie sehen nicht das Vercel-Dashboard. READMEs sagen „in .env eintragen“ ohne Zeile für Production-Hosting.

Lovable-Chat optimiert auf grüne Vorschau. Supabase und Stripe werden im Produkt verbunden. Publish übergibt an Git und Vercel. Dieser Handoff enthält keine Env-Checkliste, bis du sie baust. Das Modell hält Umgebung für erledigt, wenn die Integrationskarte „connected“ zeigt.

Stripe-Webhooks sind häufiges Opfer. Lokal leitete die Stripe CLI Events nach localhost. Produktion braucht Live-Endpoint-URL und STRIPE_WEBHOOK_SECRET vom Live-Webhook. Das Secret aus der lokalen CLI-Session gilt nicht für Vercel.

vercel env vars richtig setzen

1. Repo nach process.env und import.meta.env durchsuchen. Jeden Namen listen.
2. Vercel → Settings → Environment Variables.
3. Jeden Namen mit korrektem Wert. Production aktivieren. Preview too, wenn PR-Deploys dieselben Keys brauchen.
4. Werte vom Live-Supabase-, Stripe-, OAuth-Projekt — nicht vom Dev-Projekt.
5. Next.js Public: NEXT_PUBLIC_. Vite Client: VITE_.
6. Speichern, Deployments → Latest Production ohne Cache redeployen.
7. Live-URL, DevTools — Client-Bundles ohne leere Config.
8. Server-Route testen — Logs zeigen definierte Env-Werte (nie volle Secrets loggen).

CLI-Alternative:

vercel env add VITE_SUPABASE_URL production
vercel env pull .env.vercel.production

.env.example mit Namen only committen. Nie echte Werte. Client- vs Server-Vars dokumentieren.

Auth bricht oft im selben Deploy-Fenster — Redirect-URLs hängen an der Live-Origin, während Supabase-Keys fehlten. Nach Env-Vars Site URL und Redirect URLs zur Vercel-Domain passen. Siehe lovable login.

Env-Vars sind eine von fünf Production-Einstellungen, die KI-Editoren selten abfragen. Die lovable deploy Checkliste deckt Webhooks, RLS, Auth-URLs und TLS mit ab.

Checkliste vor Launch

• Jeder process.env– und import.meta.env-Name existiert in Vercel Production
• Production-Checkbox gesetzt, nicht nur Preview oder Development
• Client-Keys mit korrektem Public-Präfix fürs Framework
• Server-Secrets ohne Client-Präfix, nie im Browser-Bundle
• Werte passen zu Live-Supabase, Stripe, OAuth — nicht lokalen Dev-Projekten
• Redeploy nach letzter Env-Änderung
• .env.example listet Namen ohne Secret-Werte

Lokale .env beweist, dass der Code funktionieren kann. Vercel Production Env beweist, dass er für Nutzer funktioniert.

FAQ

Warum funktionieren vercel env vars lokal, nicht in Produktion?

Next.js und Vite lesen .env auf deiner Maschine. Vercel-Production-Builds nutzen nur Variablen im Dashboard oder per CLI für Production. Eine .env, die nie den Laptop verließ, ist dem Deploy unsichtbar.

Wo trage ich vercel env vars für eine Lovable-App ein?

Vercel-Projekt → Settings → Environment Variables. Jeden Key mit Production-Checkbox. Nach dem Speichern redeployen. Lovable-Vorschau-Keys kopieren sich nicht automatisch bei GitHub-Verbindung.

Muss ich nach Änderung an vercel env vars redeployen?

Ja. Bestehende Deployments haben alte Werte im Build. Variable in Vercel aktualisieren, neues Production-Deployment auslösen — Server- und Client-Bundles brauchen das.