Preview ist nicht live: KI-App richtig deployen

Du hast in Lovable, Bolt oder v0 eine App gebaut, der Preview-Link läuft, du schickst ihn rum und denkst: fertig. Dann fällt der Tab zu, ein Freund klickt den Link am nächsten Tag, und der Login hängt oder die Seite ist tot. Das ist kein Bug in deiner App. Das ist der Unterschied zwischen Preview und Production, und fast jeder Builder läuft genau einmal in diese Wand.

Die kurze Version: der Preview ist eine flüchtige Vorschau auf dem Server deines Build-Tools, kein produktiver Betrieb. „Live stellen" heißt etwas anderes, nämlich eigene Domain, persistente Daten, echter Login, stabile API-Keys und Grund-Sicherheit. Dieser Post zeigt dir, was genau zwischen Preview und Live liegt und wie du den Schritt in Minuten machst, statt ihn zum Wochenend-Projekt werden zu lassen.

Das Wichtigste in Kürze

• Der Preview-Link ist eine temporäre Vorschau auf der Infrastruktur des Build-Tools. Er kann ablaufen, gedrosselt sein oder Demo-Defaults nutzen, die in Production nicht existieren.
• 85 % der kaputten Lovable-Apps in Production scheitern an genau drei Dingen: fehlende Environment-Variablen (55 %), deaktivierte Datenbank-Sicherheit (30 %) und Login-Redirects, die auf localhost zeigen (15 %) (Afterbuild Labs, 2026).
• „Live stellen" heißt fünf Dinge gleichzeitig: eigene Domain mit HTTPS, persistente Datenbank, echter Auth-Provider, Production-API-Keys als Environment-Variablen und geschützte Endpunkte.
• Eine eigene Domain ist kein Kosmetik-Schritt. Login-Redirects, Cookies, Vertrauen und Auffindbarkeit hängen daran.

Was ist ein Preview-Link eigentlich?

Ein Preview-Link ist die automatisch erzeugte URL deines Build-Tools, die auf dessen eigene Infrastruktur zeigt. Lovable, Bolt und Co. bieten das an, damit du in Sekunden teilen kannst, was du gerade gebaut hast. Praktisch zum Vorzeigen, aber eben nicht zum Betreiben.

Das Entscheidende passiert unter der Haube. Die Preview-Umgebung ist eine managed Sandbox, die still Dinge ausfüllt, die dein echter Host nicht ausfüllt: eine funktionierende Datenbank-URL, automatisch verdrahtete Auth-Callbacks und großzügige Default-Sicherheit (Afterbuild Labs, 2026). Im Preview funktioniert deshalb alles. Es funktioniert, weil das Tool die Lücken für dich stopft.

Dazu kommt: Preview-Hosting auf einer Tool-Subdomain ist auf Vorschauen und Prototypen optimiert, nicht auf echten Traffic. Es fehlt Autoscaling, dauerhaft laufende Backend-Infrastruktur und Production-taugliche Sicherheits-Konfiguration (Lovable Docs, 2026). Der Link kann nach einer Weile einschlafen, Cold Starts machen ihn langsam, und eine eigene Adresse hat er sowieso nicht.

Merk dir den Satz so: Der Preview beweist, dass deine Idee funktioniert. Er beweist nicht, dass jemand sie benutzen kann. Das ist ein anderer Beweis, und für den brauchst du Production.

Warum reicht der Preview nicht für den echten Betrieb?

Weil im Preview alles auf Demo-Defaults läuft, in Production aber auf echten, getrennten Werten. Genau in dieser Übersetzung gehen die Dinge kaputt, die lokal nie ein Problem waren. Es ist fast immer dasselbe Muster: irgendwas, das im Build-Tool ein Automatismus war, musst du jetzt selbst setzen.

Die Zahlen sind erstaunlich eindeutig. Bei kaputten Lovable-Apps in Production verteilen sich 85 % der Fälle auf drei Ursachen: in 55 % wurden Environment-Variablen nicht in die Produktion übernommen, in 30 % war die Datenbank-Sicherheit (Row-Level Security in Supabase) deaktiviert, und in 15 % zeigten die OAuth-Redirect-URLs noch auf localhost (Afterbuild Labs, 2026). Nimmt man fehlendes SSL für die eigene Domain und Webhooks, die noch auf die Preview-URL zeigen, dazu, sind über 90 % der Deployment-Fehler abgedeckt.

Das hat einen tieferen Grund. KI-Tools sind auf den schnellen Start optimiert, nicht auf Production-Härte. Wenn ein Agent einen API-Key oder eine Datenbank-Verbindung schreibt, packt er den Wert gern direkt in den Code, damit das Beispiel sofort läuft (Modall, 2026). Im Preview ist das egal. In Production ist es ein offenes Tor. Das ist auch der Punkt, an dem viele der typischen Vibe-Coding-Deployment-Probleme zum ersten Mal sichtbar werden.

Welche fünf Dinge sich beim Live-Gehen ändern

Beim Schritt von Preview zu Production werden aus stillen Platzhaltern echte Systeme. Fünf Bausteine musst du dabei aktiv einrichten, weil das Build-Tool sie im Preview für dich erfunden hat.

Daten

Im Preview reicht eine flüchtige oder Demo-Datenbank, die du beim Bauen problemlos komplett zurücksetzen kannst. In Production sind Daten heilig, destruktive Workflows fallen weg, und Schema-Änderungen werden deutlich schwerer, sobald echte Nutzerdaten drinliegen (Convex, 2026). Du brauchst eine persistente, gebackupte Datenbank, kein SQLite-File, das parallele Schreibzugriffe nicht überlebt.

Login und Auth

Im Preview verdrahtet das Tool die Auth-Callbacks automatisch. In Production muss der Redirect auf deine echte Domain zeigen, nicht mehr auf localhost. Genau das ist die 15-Prozent-Ursache von oben. Ein Login, der im Preview tadellos lief, hängt unter deiner Domain, bis du die Redirect-URLs nachziehst.

Backend

Der Preview gaukelt dir ein dauerhaft laufendes Backend vor. Wirklich dauerhaft ist es nicht. Für echten Betrieb brauchst du einen Service, der nicht nach Inaktivität einschläft und nicht bei jedem Aufruf kalt startet.

APIs und Secrets

Test-Keys werden zu Production-Keys, und die gehören als Environment-Variablen gesetzt, nicht in den Code. Best Practice ist nüchtern: Secrets raus aus Git, pro Umgebung eigene Zugangsdaten, und Production-Werte sieht nur, wer sie braucht (GitGuardian, 2026). Eine Preview-Umgebung braucht keine Live-Zahlungsdaten, eine Production-Umgebung keine Test-Keys.

Sicherheit

Im Preview ist die Sicherheit großzügig voreingestellt, damit nichts im Weg steht. Rund 70 % der Lovable-Apps gehen mit deaktivierter Row-Level Security live (Afterbuild Labs, 2026). In Production heißt das offene Tür zu deiner Datenbank. Geschützte Endpunkte, aktive Datenbank-Regeln und HTTPS sind hier Pflicht, nicht Kür.

Warum brauchst du eine eigene Domain?

Weil an der eigenen Domain mehr hängt als ein hübscher Name. Sie entscheidet über Vertrauen, funktionierende Logins und ob dich überhaupt jemand findet. Die Default-URL des Tools ist zum Testen gedacht, eine eigene Domain ist die Adresse, unter der deine App echt wird.

Technisch besteht der Schritt aus drei Teilen: DNS, SSL und das Routing deiner Plattform. DNS übersetzt deinen lesbaren Namen in die Adresse, wo deine App tatsächlich läuft, und SSL ist das Zertifikat, das HTTPS möglich macht (Kuberns, 2026). Gute Plattformen stellen das TLS-Zertifikat automatisch aus, sobald du die Domain verbindest, meist über Let's Encrypt und ohne dass du etwas kaufst oder verlängerst.

Es gibt auch einen handfesten Funktions-Grund. Deine Auth-Redirects, deine Cookies und oft auch deine Webhooks sind an die Domain gebunden. Solange deine App unter einer wechselnden Tool-Subdomain läuft, brechen genau diese Dinge gern. Eine feste eigene Domain ist deshalb keine Marketing-Entscheidung, sondern Voraussetzung dafür, dass Login und Bezahlung stabil bleiben. Wer den kompletten Weg dorthin sucht, findet ihn in App live bringen: von der Idee zur echten URL.

Was „live stellen" bei lowcloud konkret heißt

Bei lowcloud sehen wir aus den Deploys, die Vibe-Coder bei uns machen, fast immer denselben Stolperstein: die App läuft im Preview, und der Schritt zu Production fühlt sich nach Server-Stress an, obwohl er es nicht sein muss. Live stellen heißt bei uns drei Dinge in Folge, nicht ein DevOps-Projekt.

Erstens verbindest du dein GitHub-Repo, und ein Container wird gebaut. Der Push-to-Deploy-Flow bleibt genau wie im Build-Tool, du pushst und es deployt. Zweitens setzt du deine Environment-Variablen als Secrets, die zur Build- und Laufzeit injiziert werden und nie im Code oder in Build-Logs auftauchen. Damit ist die 55-Prozent-Ursache von oben vom Tisch. Drittens hängst du deine Domain an, und das TLS-Zertifikat kommt automatisch dazu.

Dahinter läuft persistente Infrastruktur statt einer Sandbox: managed Postgres für Daten, die bleiben sollen, dauerhaft laufende Container statt Cold Starts, und aktive Sicherheits-Defaults. Und ja, nebenbei liegt das Ganze auf Servern in Deutschland, falls dir oder deinen Nutzern das wichtig ist. Der Aufhänger bleibt aber simpel: deine KI-App soll richtig live sein, und zwar ohne dass du dafür Reverse-Proxies und CI-Pipelines lernen musst. Wie das vom Tool zur Live-URL aussieht, zeigt auch Vibe-Coded App deployen.

Preview gegen Production im direkten Vergleich

Die folgende Tabelle stellt die fünf Bausteine nebeneinander, damit du siehst, was sich pro Punkt wirklich ändert.

Die Auswertung ist unbequem einfach: keiner dieser Punkte ist im Preview „falsch". Sie sind nur bequem für dich vorbelegt. Live gehen heißt, jeden dieser sechs Werte einmal bewusst zu setzen, und danach läuft die App stabil unter echten Bedingungen.

Häufige Fragen

Läuft mein Lovable-Preview-Link dauerhaft?

Verlass dich nicht darauf. Die Preview-Subdomain ist auf Vorschauen optimiert, nicht auf echten Traffic, und es fehlen Autoscaling und dauerhaft laufende Backend-Infrastruktur (Lovable Docs, 2026). Für etwas, das User wirklich nutzen, brauchst du ein Production-Deployment mit eigener Domain und persistentem Backend. Was du außerdem brauchst, um eine KI-App für Kunden zu veröffentlichen, geht ein eigener Beitrag durch.

Warum funktioniert der Login im Preview, aber nicht unter meiner Domain?

Weil die Auth-Redirect-URLs noch auf localhost oder die Preview-URL zeigen. Das ist die Ursache in rund 15 % der kaputten Production-Apps (Afterbuild Labs, 2026). Sobald du die Redirects auf deine echte Domain setzt, funktioniert der Login auch live.

Brauche ich für „live" wirklich eine eigene Datenbank?

Ja, sobald echte Nutzer Daten speichern. Im Preview kannst du Daten beim Bauen folgenlos zurücksetzen, in Production werden Schema-Änderungen schwer, und ein einfaches Datei-basiertes Setup überlebt parallele Schreibzugriffe nicht (Convex, 2026). Eine persistente, gebackupte Datenbank ist Pflicht.

Was ist der häufigste Fehler beim Live-Gehen?

Vergessene Environment-Variablen. In 55 % der kaputten Production-Apps wurden Secrets und Keys nicht in die Produktion übernommen (Afterbuild Labs, 2026). Setz deine Keys als Production-Environment-Variablen und halte sie aus dem Code und aus Git heraus.

Ist mein Preview öffentlich und sicher?

Funktional offen, sicherheitstechnisch schwach. Die Preview-Umgebung nutzt großzügige Default-Sicherheit, und rund 70 % der Apps gehen mit deaktivierter Row-Level Security live (Afterbuild Labs, 2026). Aktiviere Datenbank-Regeln und geschützte Endpunkte, bevor echte Daten reinkommen.

Fazit

Der Preview ist ein guter Beweis, aber der falsche. Er zeigt, dass deine Idee funktioniert, nicht dass jemand sie sicher benutzen kann. Zwischen beidem liegen fünf Dinge: eigene Domain, persistente Daten, echter Login, Production-Keys und aktive Sicherheit. Klingt nach viel, ist aber Routine, sobald die Plattform die langweiligen Teile übernimmt. Du setzt deine Werte einmal bewusst, statt dich auf Demo-Defaults zu verlassen, und danach läuft die App unter echten Bedingungen stabil. Das ist der ganze Unterschied zwischen „läuft im Preview" und „ist live".

Bring deine KI-App in wenigen Minuten richtig live: jetzt bei lowcloud deployen.