Lovable-App exportieren, hosten und betreiben: Wege, Fallstricke, Betrieb

Zusammenfassung: Eine Lovable-App lässt sich auf drei Wegen betreiben: bei Lovable (am einfachsten, eigene Domain nur im Bezahltarif), Frontend bei einem Hoster wie Vercel oder Netlify plus eigenes Supabase-Projekt, oder auf einem eigenen Server in Deutschland mit eigener PostgreSQL-Datenbank. Für Unternehmensanwendungen mit Personendaten empfehlen wir meist den dritten Weg. Der Code gehört dir: Über die GitHub-Synchronisation, die in beide Richtungen arbeitet, bekommst du ihn in jedem Tarif heraus. Zwei Dinge haben sich 2026 geändert: Seit Mai 2026 erzeugt Lovable standardmäßig TanStack-Start-Apps, die einen Server brauchen, ein reines Datei-Hosting reicht dafür nicht mehr. Und ein Backend in Lovable Cloud lässt sich nicht per Klick in ein eigenes Supabase-Projekt umziehen. Wer früh weiß, wohin die Reise geht, spart sich später eine Migration. Egal welcher Weg: Ab dem Moment, in dem echte Nutzer da sind, braucht die App Backups, Überwachung, Updates und jemanden, der zuständig ist.

Inhaltsverzeichnis

1. Wo eine Lovable-App läuft, wenn du nichts änderst
2. Code exportieren: GitHub-Sync und ZIP
3. Die drei Hosting-Wege im Vergleich
4. Was 2026 neu ist: TanStack Start braucht einen Server
5. Lovable Cloud oder eigenes Supabase?
6. Eigene Domain und Livegang
7. Nach dem Launch: Was der Betrieb braucht

Wo eine Lovable-App läuft, wenn du nichts änderst

Veröffentlichst du eine App direkt aus Lovable, besteht sie aus zwei Teilen:

• Frontend: Die Oberfläche wird laut Lovable immer weltweit ausgeliefert, als eigener Worker auf der Infrastruktur von Cloudflare. Die Adresse lautet zunächst deinprojekt.lovable.app.
• Backend: Datenbank, Login, Dateiablage und Serverfunktionen laufen entweder in Lovable Cloud (basiert auf Supabase, Regionen Americas, Europe oder Asia Pacific) oder in einem eigenen Supabase-Projekt, das du mit Lovable verbunden hast.

Für Prototypen und interne Tests ist das ideal. Sobald Kunden, Personendaten oder Zahlungen ins Spiel kommen, stellen sich drei Fragen: Auf wessen Konto läuft das alles? Wo liegen die Daten? Und wer kümmert sich, wenn etwas ausfällt?

Code exportieren: GitHub-Sync und ZIP

Den Code bekommst du auf zwei Wegen heraus:

• GitHub-Synchronisation: Lovable verbindet ein Projekt mit einem Repository bei GitHub (alternativ GitLab oder Bitbucket). Die Synchronisation läuft in beide Richtungen: Änderungen aus Lovable landen im Repository, und was du auf den aktiven Branch pushst, übernimmt Lovable. Laut Lovable ist das in allen Tarifen verfügbar.
• ZIP-Download: Den Code als Archiv herunterladen geht nur in Bezahltarifen.

Empfehlung für Unternehmen: Verbinde das Projekt früh mit einem Repository, das dem Unternehmen gehört, nicht dem privaten GitHub-Konto der Person, die die App gebaut hat. Damit ist der Code versioniert, gesichert und unabhängig von Lovable. Und es wird möglich, was im Betrieb unverzichtbar ist: Änderungen nachvollziehen, eine Testumgebung bauen, einen Stand zurückholen.

Achtung, Datenbank: Der Code im Repository beschreibt nicht automatisch die Datenbank. Wurden Tabellen oder Regeln direkt im Supabase-Dashboard geändert, fehlen diese Änderungen in den Migrationen. Dann lässt sich die Anwendung aus dem Repository allein nicht wiederherstellen. Diese Abweichung ist einer der häufigsten Befunde in unseren Prüfungen.

Die drei Hosting-Wege im Vergleich

Weg 1 — Bei Lovable bleiben. Am wenigsten Aufwand, aber die meisten Abhängigkeiten. Für Unternehmensdaten wichtig: Einen Auftragsverarbeitungsvertrag bietet Lovable nur in den Tarifen Business und Enterprise an. Details im Ratgeber Supabase, Lovable & Vercel DSGVO-konform betreiben.

Weg 2 — Frontend bei einem Hoster, Backend im eigenen Supabase-Projekt. Ein schneller Zwischenschritt, wenn die App aus Lovable Cloud heraus soll, ohne dass schon ein eigener Server betrieben wird. Du baust weiter mit Lovable, das Repository ist die Quelle, und ein Hoster wie Vercel oder Netlify veröffentlicht automatisch jeden Stand. Die Datenbank liegt in deinem eigenen Supabase-Projekt in einer EU-Region, mit eigenem Vertrag. Achte bei Vercel darauf, die Funktionsregion von der US-Standardeinstellung auf eine EU-Region umzustellen. Beide Anbieter sind allerdings US-Unternehmen; was das bedeutet, steht im DSGVO-Ratgeber.

Weg 3 — Eigener Server in Deutschland mit PostgreSQL. Anwendung und Datenbank laufen auf einem eigenen virtuellen Server bei einem deutschen Anbieter wie Hetzner, die Daten in einer eigenen PostgreSQL-Datenbank. Das ist der Weg, den wir Unternehmen mit Personendaten meist empfehlen: kein US-Anbieter im Kern der Anwendung, ein Vertragspartner in Deutschland, volle Kontrolle über Backups und Updates und planbare Kosten.

Weil Supabase selbst auf PostgreSQL aufbaut, lassen sich Daten und Tabellen gut übertragen. Login, Dateiablage und Serverfunktionen, die Supabase sonst mitbringt, müssen dann ersetzt werden, entweder durch eigene Bausteine oder durch eine selbst betriebene Supabase-Installation auf dem Server. Der Preis für die Unabhängigkeit ist Betriebsaufwand: Jemand muss Server und Datenbank dauerhaft pflegen, sichern und überwachen. Das lohnt sich, sobald die Anwendung geschäftskritisch ist — und es ist genau die Arbeit, die sich gut an einen Dienstleister abgeben lässt.

Was 2026 neu ist: TanStack Start braucht einen Server

Ältere Lovable-Apps sind klassische React-Anwendungen mit Vite. Ein Build erzeugt einen Ordner mit statischen Dateien, die auf jedem einfachen Webspace laufen.

Seit dem 13.05.2026 erzeugt Lovable neue Projekte standardmäßig mit TanStack Start. Diese Apps nutzen serverseitiges Rendering und Serverfunktionen. Sie brauchen deshalb einen Hoster, der Server-Code ausführt, etwa Vercel, Netlify, Cloudflare oder einen eigenen Node-Server. Ein reines Datei-Hosting oder ein klassischer Webspace reicht nicht mehr.

Prüfe vor dem Umzug also zuerst, welche Art von Projekt du hast. Ein Blick in die package.json zeigt es: Steht dort TanStack Start, brauchst du einen Server.

Ein zweiter Punkt beim Umzug: Umgebungsvariablen mit dem Präfix VITE_ werden beim Build fest in den ausgelieferten Code eingebettet. Sie sind damit für jeden Besucher lesbar. Dort darf nur stehen, was öffentlich sein darf, etwa die Projektadresse und der öffentliche Schlüssel von Supabase. Geheime Schlüssel gehören nie in eine VITE_-Variable.

Lovable Cloud, Supabase oder eigene Datenbank?

Lovable Cloud ist bequem: Datenbank, Login und Dateiablage sind mit einem Klick da. Für einen Prototyp ist das die schnellste Lösung. Für eine Anwendung, die bleiben soll, hat es Nachteile:

• Die Region wird bei der Aktivierung gewählt und ist danach fest.
• Einen Umzug per Klick zu einem eigenen Supabase-Projekt gibt es nicht. Laut Lovable exportierst du die Daten, verbindest ein eigenes Projekt und baust das Schema dort neu auf.
• Vertragspartner für die Daten ist Lovable, mit AVV erst ab dem Business-Tarif.

Ein eigenes Supabase-Projekt kostet etwas mehr Einrichtung, bringt aber Kontrolle: Du wählst die EU-Region genau, schließt den AVV direkt mit Supabase, hast Zugriff auf alle Einstellungen und behältst die Datenbank, falls du Lovable später nicht mehr nutzt.

Eine eigene PostgreSQL-Datenbank auf einem Server in Deutschland geht noch einen Schritt weiter: Kein US-Anbieter hält die Daten, Backups und Aufbewahrung bestimmst du selbst. Dafür übernimmst du (oder ein Dienstleister) den Betrieb.

Zwei Supabase-Fakten, die beim Wechsel oft überraschen:

• Kostenlose Projekte werden nach einer Woche Inaktivität pausiert und haben keine automatischen Backups. Für eine produktive Anwendung ist der Pro-Tarif (ab 25 $ pro Monat) die Untergrenze.
• Hochgeladene Dateien sind nicht im Datenbank-Backup enthalten. Dokumente, Bilder und Verträge brauchen eine eigene Sicherung.

Unsere Faustregel: Für Prototypen ist Lovable Cloud in Ordnung. Wird die App von mehr als einer Handvoll Menschen genutzt oder liegen Personendaten darin, gehört sie aus Lovable Cloud heraus. Für geschäftskritische Unternehmensanwendungen empfehlen wir einen eigenen Server in Deutschland mit PostgreSQL. Je früher die Entscheidung fällt, desto kleiner die Migration.

Eigene Domain und Livegang

Eine eigene Domain wie app.deinefirma.de verbindest du entweder direkt in Lovable (nur im Bezahltarif) oder beim jeweiligen Hoster. In beiden Fällen setzt du beim Domain-Anbieter einen DNS-Eintrag, das Zertifikat entsteht meist automatisch. Vor dem Umschalten auf die echte Domain sollte geklärt sein:

1. Laufen Zahlungen und Logins im Live-Modus, nicht mehr in der Test-Konfiguration?
2. Ist ein eigener Mailversand für Registrierung und Passwort-Reset eingerichtet? Der eingebaute Versand von Supabase ist nur für Tests gedacht und schickt höchstens zwei Mails pro Stunde.
3. Sind Impressum und Datenschutzerklärung vorhanden und nennen alle beteiligten Dienste?
4. Hat jede Tabelle mit Personendaten Zugriffsregeln, die pro Nutzer schützen?
5. Gibt es eine Testumgebung, in der Änderungen ausprobiert werden, bevor sie live gehen?

Was sonst vor dem Livegang auf die Liste gehört, steht im 10-Fragen-Check.

Nach dem Launch: Was der Betrieb braucht

Mit dem Livegang beginnt die Arbeit, die beim Bauen niemand sieht. Eine produktive Anwendung braucht:

• Überwachung: Automatische Prüfungen, ob die App erreichbar ist und die Kernfunktionen laufen — Login, Zahlungen, Mailversand. Dazu eine Fehlererfassung, damit du von Problemen erfährst, bevor Kunden anrufen.
• Backups mit Probe: Tägliche Sicherung der Datenbank, eine separate Sicherung der Dateien, idealerweise eine Kopie außerhalb des Anbieters. Und mindestens einmal ein echter Wiederherstellungstest.
• Updates: Bibliotheken bekommen laufend Sicherheitsupdates. Wer sie nicht einspielt, sammelt bekannte Lücken an. Wer sie ungetestet einspielt, riskiert Ausfälle.
• Saubere Änderungen: Datenbankänderungen nur über Migrationen im Repository, nicht im Dashboard. Neue Funktionen erst in der Testumgebung, dann live.
• Zuständigkeit: Wer reagiert, wenn nachts der Login nicht geht? Wer entscheidet, ob ein Update eingespielt wird? Auf wessen Namen laufen die Konten?
• Kosten im Blick: Datenbank, Hosting, Mailversand und KI-Schnittstellen rechnen oft nach Nutzung ab. Ein monatlicher Blick auf die Rechnungen verhindert Überraschungen.

Für typische Unternehmensanwendungen liegt die reine Infrastruktur meist im zwei- bis niedrigen dreistelligen Euro-Bereich pro Monat. Der größere Posten ist die Zeit für Betrieb und Pflege. Viele Teams teilen deshalb die Arbeit: Wer die App gebaut hat, baut weiter Funktionen, und ein Dienstleister übernimmt Überwachung, Updates, Backups und Störungen. Wie das bei einem selbst gebauten Unternehmens-Intranet aussieht, zeigt der Ratgeber Citizen Developer & Schatten-IT.

Was in den Top-10-Google-Ergebnissen zu „Lovable Hosting” steht

Die Treffer zu „Lovable Hosting” sind vor allem die Dokumentation von Lovable, Reddit-Threads und einzelne Anleitungen zum Selbsthosten. Sie beantworten, wie man eine App technisch woanders hinstellt. Was fehlt, ist die Entscheidung davor: Welcher Weg passt zu welcher Anwendung, was bedeutet die Umstellung auf TanStack Start, warum ist der Umzug aus Lovable Cloud aufwendig, und was braucht die App, nachdem sie umgezogen ist? Darum geht es in diesem Artikel.

---

FAQ

Kann ich eine Lovable-App selbst hosten?

Ja. Lovable schreibt ausdrücklich, dass mit Lovable gebaute Anwendungen überall gehostet werden können. Ältere Vite-Projekte laufen als statische Dateien auf jedem Webspace. Neuere Projekte mit TanStack Start (Standard seit Mai 2026) brauchen einen Hoster, der Server-Code ausführt.

Wie exportiere ich ein Lovable-Projekt?

Am besten über die GitHub-Synchronisation, die in allen Tarifen verfügbar ist und in beide Richtungen arbeitet. Alternativ gibt es in Bezahltarifen einen ZIP-Download. Die Datenbank exportierst du separat, bei Lovable Cloud über die erweiterten Einstellungen.

Kann ich nach dem Export weiter mit Lovable arbeiten?

Ja. Über die GitHub-Synchronisation baust du weiter in Lovable, und der Hoster veröffentlicht jeden neuen Stand aus dem Repository. Wichtig ist, dass das Repository die einzige Quelle bleibt und Datenbankänderungen als Migrationen darin landen.

Kann ich von Lovable Cloud zu meinem eigenen Supabase wechseln?

Ja, aber nicht per Klick. Laut Lovable exportierst du die Daten, verbindest ein eigenes Supabase-Projekt und baust das Schema dort neu auf. Der umgekehrte Weg von Supabase zu Lovable Cloud wird nicht unterstützt. Je früher der Wechsel, desto kleiner die Migration.

Kann eine Lovable-App ohne Supabase laufen?

Ja, mit Umbau. Da Supabase auf PostgreSQL basiert, lassen sich Daten und Tabellen in eine eigene PostgreSQL-Datenbank übertragen, etwa auf einem Server in Deutschland. Login, Dateiablage und Serverfunktionen müssen dann durch eigene Bausteine ersetzt oder als selbst betriebene Supabase-Installation weitergeführt werden. Für Unternehmensanwendungen mit Personendaten ist das unsere übliche Empfehlung.

Brauche ich für eine eigene Domain einen bezahlten Lovable-Tarif?

Wenn die App bei Lovable veröffentlicht wird: ja. Hostest du das Frontend selbst oder bei einem anderen Anbieter, verbindest du die Domain dort.

Was kostet der Betrieb einer Lovable-App?

Die Infrastruktur — Server oder Datenbank-Dienst, Mailversand, Backup-Speicher — liegt für typische Unternehmensanwendungen meist im zwei- bis niedrigen dreistelligen Euro-Bereich pro Monat. Dazu kommt die Zeit für Überwachung, Updates, Backups und Störungen, intern oder bei einem Dienstleister.

---

Raus aus dem Prototyp, rein in den Betrieb

Du willst deine Lovable-App aus dem Prototyp-Stadium in einen sauberen Betrieb bringen, auf einem eigenen Server in Deutschland, mit Backups und Überwachung? Wir prüfen den aktuellen Stand, planen den Umzug und übernehmen auf Wunsch den laufenden Betrieb, während du weiter mit Lovable baust.

• → Code-Review für selbst gebaute Software
• → Kostenloses Erstgespräch

Verwandte Ratgeber & Leistungen

• → Supabase, Lovable & Vercel DSGVO-konform betreiben
• → Vibe Coding: Risiken und 10-Fragen-Check
• → Citizen Developer & Schatten-IT
• → Web-App-Entwicklung

Quellen

• Lovable: GitHub-Integration — docs.lovable.dev
• Lovable: Deployment, Hosting & Ownership — docs.lovable.dev
• Lovable: External Deployment & Hosting — docs.lovable.dev
• Lovable: Hosting — docs.lovable.dev
• Lovable: Lovable Cloud — docs.lovable.dev
• Lovable: „How we migrated lovable.dev away from Next.js” (18.08.2026) — lovable.dev/blog
• Supabase: Database Backups — supabase.com/docs
• Supabase: Custom SMTP — supabase.com/docs
• Supabase: Pricing — supabase.com/pricing
• Vercel: Configuring Regions for Functions — vercel.com/docs

---

Über den Autor: Moritz Lehmann ist Geschäftsführer von Adfera (M.Sc. Wirtschaftsinformatik). Er baut, prüft und betreibt Web-Anwendungen und bringt selbst gebaute Apps aus dem Prototyp-Stadium in einen sicheren Betrieb.