Du hast lovable github verdrahtet, saubere Commits gepusht — und hast trotzdem keine Live-App, weil das Repo nicht dasselbe ist wie Production-Hosting.
Export fühlte sich nach Freiheit an. Versionskontrolle, CI, eigenes Vercel-Team. Der erste Push klappte. Vercel baute grün oder scheiterte an fehlender Config. Die Live-URL lädt eine Hülle, Auth stirbt oder Env-Fehler fluten das Log. Lovable-Vorschau läuft noch im Editor. GitHub hält Code. Nicht Supabase Site URL, Stripe-Webhooks oder den Production-Env-Drawer.
Was du nach lovable github Sync siehst
Muster wiederholen sich in Foren.
- Repo da, Site nicht. GitHub zeigt Dateien. Kein Deployment verbunden oder falscher Branch.
- Vercel-Build scheitert. Framework-Erkennung falsch, Node-Version passt nicht oder Build-Command fehlt.
- Build grün, Runtime leer. Env-Vars nie von Lovable-Vorschau nach Vercel Production kopiert.
- Auth-Schleife auf Vercel-URL. Supabase Redirect URLs ohne
*.vercel.appoder Custom Domain. - Zwei Wahrheiten. Du editierst in Lovable und GitHub; letzter Sync überschreibt manuelle Fixes.
- Secrets in Git-History. Panik nach
.env-Commit — Keys rotieren vor Go-Live.
Code aus Lovable ist Schritt eins. Die lovable deploy-Checkliste ist Schritt zwei bis fünf: Auth-URLs, Webhooks, RLS, Env, SSL.
Warum lovable github Production nicht mitliefert
Lovables GitHub-Integration spiegelt Projektdateien. Sie provisioniert kein Vercel, Netlify oder DNS. Die KI baute gegen Vorschau-Keys im Editor. Diese Integrationen bleiben in Lovable — bis du sie abschreibst.
Vercel klont das Repo und führt npm run build aus. Env liest es aus dem Vercel-Dashboard — nicht aus Lovables Supabase-Panel. Ein erfolgreicher Git-Push kopiert kein VITE_SUPABASE_URL nach Production. Siehe vercel env vars für Copy-and-Redeploy.
Auth bricht auf neuem Hostname aus demselben Grund wie beim ersten Publish. Supabase erlaubt Vorschau und localhost. Dein neues project.vercel.app oder Custom Domain steht nicht in der Liste, bis du es hinzufügst. OAuth in Google Cloud hat dieselbe Lücke.
Custom Domains brauchen DNS und SSL nach GitHub. Repo und Domain verbinden sind getrennte Klicks. SSL pending während du Auth testest erzeugt falsche „github hat meine App kaputt gemacht“-Meldungen.
Die KI kann eine README mit Deploy-Schritten erzeugen. Vercel Import oder Production-Checkboxen kann sie nicht klicken. Diese manuelle Lücke ist die Produktgrenze — kein gescheiterter Export.
Teams, die GitHub als „fertig“ werten, überspringen dieselben fünf Production-Einstellungen wie beim ersten Lovable-Publish. Export ändert, wo du editierst — nicht, was Production braucht: Live-Secrets, Auth-Allowlists, Webhook-Endpoints, Row-Policies, gültiges TLS.
Nach lovable github deployen — Schritt für Schritt
- GitHub-Repo und Branch bestätigen. Default oft
main. Lovable sollte bei Publish dorthin pushen. Letzten Commit-Zeitstempel auf GitHub prüfen. - In Vercel importieren (oder anderen Host). New Project → Import Git Repository. Lovable-Repo wählen. Framework-Preset zu Vite oder Next passend setzen.
- Build-Einstellungen setzen. Install-, Build-Command, Output-Verzeichnis — wie Lovable. Falsches Output-Dir serviert leeren Ordner.
- Jede Env-Var nach Vercel Production kopieren. Lovable-Integrationen oder lokales
.env.exampleöffnen. Jeden Namen in Vercel → Settings → Environment Variables mit Production aktiv hinzufügen. - Deployen, wenn Env vollständig. Production-Deployment anstoßen. Build-Log auf fehlende Module oder Type-Errors lesen.
- Supabase URL Configuration aktualisieren. Vercel-Production-URL, Preview-URLs und Custom Domain zu Site URL und Redirect URLs hinzufügen.
- Stripe-Webhooks auf Live-Vercel-Domain registrieren.
whsec_in Vercel Production Env. Redeploy. - Custom Domain in Vercel anhängen, falls nötig. DNS und SSL fixen, bevor du die Standard-Lovable-URL aus Auth-Allowlists entfernst.
- Edit-Workflow wählen. Lovable → GitHub weiter syncen oder nur im Repo arbeiten. Festlegen, welche Seite gewinnt — gegen Überschreib-Überraschungen.
Nach dem ersten erfolgreichen Vercel-Deploy im privaten Fenster auf der Vercel-URL testen — nicht nur in Lovable-Vorschau.
Checkliste nach verbundenem lovable github
- GitHub-Repo hat aktuelle Commits aus Lovable oder IDE
- Host-Projekt mit Repo und richtigem Branch verknüpft
- Production-Deployment-Status ist Ready
- Alle Client- und Server-Env-Vars für Production auf dem Host
- Supabase Redirect URLs enthalten Vercel und Custom Domains
- Keine Secrets committed — rotieren, falls
.envgepusht wurde - Live-URL besteht Login und eine Datenoperation
- Team weiß, ob Lovable oder Git Source of Truth ist
FAQ
Was passiert nach dem Verbinden von lovable github?
Lovable synchronisiert dein Projekt bei Publish oder manuellem Sync mit einem GitHub-Repository. Das Repo enthält Quellcode, keine Production-Secrets, kein DNS und keine Supabase-URL-Konfiguration. Du brauchst weiterhin Host, Env-Vars und Auth-Dashboard-Updates.
Warum bricht die App nach lovable github Export zu Vercel?
Vercel baut aus dem Repo ohne Lovable-Vorschau-Secrets. Fehlende VITE_- oder NEXT_PUBLIC_-Vars, falsche Framework-Einstellungen oder Auth auf localhost verursachen dieselben Fehler wie beim ersten Publish.
Nutze ich Lovable noch nach github-Verbindung?
Du kannst weiter in Lovable editieren und syncen oder nur im Repo mit Cursor o. ä. arbeiten. Production hängt in beiden Fällen von Host-Env und Supabase-Einstellungen ab — nicht allein vom Lovable-Secret-Drawer.