Vom Programmieren bis zur Produktion: Die Infrastruktur, die dir dein KI-Builder nicht bietet

Ein Gründer erstellt an einem Wochenende mit einem KI-App-Builder eine App und teilt den Link am Montag. Am Freitag hat die App bereits zahlende Nutzer, und jemand stellt eine einfache Frage: Was passiert, wenn die Datenbank ausfällt? Diese Frage markiert die Grenze zwischen einer funktionierenden App und einer Produktions-App.

KI-App-Builder wie Lovable, Bolt, Replit und v0 kümmern sich mittlerweile um das Hosting, eine Datenbank und die Anmeldung für eine einzelne App. Was sie dir in der Regel nicht bieten, ist die Infrastruktur, auf die ein wachsendes Produkt angewiesen ist:

• Umgebungen, die der Produktivumgebung entsprechen, damit jede Änderung sicher getestet werden kann, bevor die Nutzer sie sehen.
• Volle Kontrolle über deine Daten, einschließlich backups, Wiederherstellungen und Datenbankmigrationen.
• Hintergrundverarbeitung, wie geplante Jobs, Worker und queues.
• Einblick in Probleme durch Protokolle, Metriken und Warnmeldungen.
• Team-Workflows, wie Code-Reviews, automatisierte Tests und eine Änderungshistorie.
• Compliance und Portabilität, damit die App Kundenanforderungen erfüllt und bei Bedarf migriert werden kann.

Der Übergang in die Produktivumgebung bedeutet in der Regel, das Programm nach Git zu exportieren und auf einer Plattform bereitzustellen, die diese Komponenten bietet. Im weiteren Verlauf dieses Leitfadens wird erläutert, was App-Builder heute abdecken, wo Apps häufig Probleme bereiten und wie sich die jeweiligen Lücken schließen lassen.
 

Was bieten dir KI-App-Builder im Jahr 2026?

KI-App-Builder bieten dir weit mehr als nur einen Prototyp. Die meisten umfassen mittlerweile Hosting, eine verwaltete Datenbank, eine Anmeldemöglichkeit und eine Form des Git-Exports. Die folgende Tabelle fasst zusammen, was die vier beliebtesten Builder standardmäßig bieten.

Das ist echter Fortschritt, und für viele Apps reicht das aus. Die Lücken treten auf, wenn eine App zahlende Nutzer, ein Team oder Datenverpflichtungen bekommt. Genau dort entstehen die meisten Probleme in der Produktivumgebung.

Warum gehen „Vibe-codierte“ Apps in der Produktivumgebung kaputt?

Spontan programmierte Apps versagen meist aus betrieblichen Gründen, nicht weil die Idee oder die Benutzeroberfläche falsch ist. Zwei öffentlich bekannte Vorfälle verdeutlichen das Muster.

Im Juli 2025 löschte ein KI-Agent auf Replit während eines Code-Freezes eine Live-Produktionsdatenbank. Die Datenbank enthielt Datensätze von mehr als 1.200 Führungskräften und etwa 1.190 Unternehmen. Die Daten konnten durch ein Rollback wiederhergestellt werden, und Replit trennte daraufhin standardmäßig Entwicklungs- und Produktionsdatenbanken voneinander.

Im Mai 2025 machte der Forscher Matt Palmer die Sicherheitslücke CVE-2025-48757 öffentlich. Bei mehr als 170 mit Lovable erstellten Apps fehlten Sicherheitsregeln auf Zeilenebene oder diese waren unzureichend. Jeder, der den öffentlichen API-Schlüssel hatte, konnte Daten wie E-Mails, Telefonnummern und den Zahlungsstatus einsehen. Lovable hat seitdem schnelle und gründliche Sicherheitsscans eingeführt.

Umfassendere Studien kommen zu dem gleichen Ergebnis. Ein Scan von Symbiotic Security im Juni 2026 an 1.072 mit Vibe programmierten Apps ergab, dass 98 % davon mindestens eine Sicherheitslücke und 16 % eine kritische Schwachstelle aufwiesen. Eine CodeRabbit-Analyse von 470 open source Pull-Requests ergab, dass von KI geschriebener Code etwa 1,7-mal mehr Probleme aufwies als von Menschen geschriebener Code. Beide Studien stammen von Unternehmen, die Tools für Codesicherheit oder Codeüberprüfung verkaufen – daher solltest du die genauen Zahlen mit einer gewissen Vorsicht betrachten. Der Tenor ist dennoch einheitlich: KI-generierte Apps benötigen die gleichen Prüfungen, die Produktionssoftware schon immer benötigt hat.

Welche Infrastruktur benötigt eine Produktions-App, die von den Entwicklungswerkzeugen nicht bereitgestellt wird?

Eine Produktions-App benötigt eine Reihe von Funktionen rund um das Programmieren. Entwickler decken einige davon für eine einzelne App ab. Die Tabelle zeigt, wo die Lücken normalerweise liegen.

Kannst du eine Änderung anhand echter Daten testen, bevor sie den Nutzern angezeigt wird?

Bei den meisten Entwicklungsumgebungen kannst du eine Vorschau einer Änderung anzeigen, aber die Vorschau läuft selten mit produktionsähnlichen Diensten und Daten. Dadurch bleiben die wichtigsten Fehler verborgen, wie zum Beispiel eine Migration, die bei echten Datensätzen fehlschlägt. Auf Upsun Cloud kann jeder Git-Zweig eine Vorschauumgebung erhalten, die Produktions-Apps, -Dienste und -Daten in Sekundenschnelle klont. 

Wem gehören deine Datenbank und ihre backups?

Von der Plattform verwaltete Datenbanken sind praktisch, lassen sich aber oft nur schwer migrieren. In der Dokumentation von Lovable heißt es, dass es keine Ein-Klick-Migration von der Lovable Cloud zu deinem eigenen Supabase-Projekt gibt und die Region nach der Einrichtung nicht mehr geändert werden kann. Eine Produktionsdatenbank benötigt planmäßige backups, eine von dir getestete Wiederherstellung und Migrationen, die von einem reviewer überprüft werden.

Wo werden Hintergrundaufgaben ausgeführt?

Echte Produkte versenden E-Mails, wickeln Zahlungen ab und synchronisieren Daten nach einem Zeitplan. Edge-Funktionen eignen sich gut für kurze Aufgaben, aber lang laufende Worker und geplante Jobs benötigen eine eigene Laufzeitumgebung. Upsun Cloud definiert Worker und Cron-Jobs in derselben Konfigurationsdatei wie die App. 

Wie erfährst du, wenn etwas nicht mehr funktioniert?

Ohne Protokolle, Metriken und Warnmeldungen werden deine Nutzer zu deinem Überwachungssystem. In der Produktivumgebung zeigt sich das System durch Fehler, langsame Anfragen und die Ressourcennutzung an einem Ort. Es benachrichtigt jemanden, bevor es die Kunden bemerken.

Was passiert, wenn du weitere Apps hinzufügst?

Eine „Vibe-codierte“ App lässt sich leicht im Blick behalten. Fünf Apps auf Lovable, Replit und Vercel bedeuten fünf Deployment-Prozesse, fünf Datenbankkonsolen und fünf Sätze von Zugriffsregeln. Diese Ausuferung verlangsamt Sicherheitsüberprüfungen und Audits, da sich die Nachweise an verschiedenen Orten befinden.

Ist deine mit Vibe programmierte App bereit für die Produktion? Eine Checkliste

Eine App ist bereit für die Produktivumgebung, wenn sie alle diese Prüfungen besteht. Jeder Punkt steht für sich allein, sodass du sie in beliebiger Reihenfolge abarbeiten kannst.

• Jede Datenbanktabelle verfügt über Zugriffsregeln, und du hast diese mit einem zweiten Benutzerkonto getestet.
• Im Programm oder im Browser-Bundle tauchen keine API-Schlüssel oder Passwörter auf.
• Geheimnisse und Umgebungskonfigurationen werden auf der Hosting-Plattform gespeichert, nicht im Repository.
• Backups werden nach einem Zeitplan ausgeführt, und du hast eines erfolgreich wiederhergestellt.
• Datenbankänderungen werden als geprüfte Migrationen durchgeführt, nicht als Ad-hoc-Bearbeitungen.
• Jede Änderung wird vor der Freigabe in einer Umgebung getestet, die der Produktivumgebung entspricht.
• Fehler lösen eine Benachrichtigung aus, die eine Person erreicht.
• Hintergrundjobs laufen außerhalb der Webanfrage.
• Abhängigkeiten werden auf bekannte Schwachstellen überprüft.
• Das Programmieren findet in einem Git-Repository statt, das dir gehört.
• Eine Person oder ein Überprüfungsschritt prüft jede Änderung, bevor sie live geschaltet wird.
• Du weißt, in welcher Region die Daten deiner Nutzer gespeichert sind.

Wie bringst du eine „Vibe-codierte“ App in die Produktivumgebung?

Die Überführung einer mit Vibe programmierten App in die Produktivumgebung erfolgt in neun Schritten. Die meisten Apps müssen nicht neu geschrieben werden.

1. Exportiere das Programmieren in ein Git-Repository, das dir gehört. Lovable und v0 synchronisieren sich mit GitHub, Replit unterstützt mehrere Git-Anbieter und Bolt unterstützt den Export.
2. Stelle fest, wie die App tatsächlich aufgebaut ist. Viele Builder-Apps sind ein Frontend, das direkt mit einem gehosteten Backend wie Supabase kommuniziert. Entscheide, ob du dieses Backend beibehalten oder auf deine eigene Datenbank umsteigen möchtest. Beides sind gültige Optionen.
3. Überprüfe das Programmieren, bevor du es überträgst. Führe den Sicherheitsscan des Builder-Tools durch, teste jede Zugriffsregel mit einem zweiten Konto und entferne alle Schlüssel aus dem Frontend.
4. Beschreibe die Infrastruktur als Code. Eine einzige Konfigurationsdatei kann die App, ihre Datenbank und ihre geplanten Jobs definieren. Das folgende Beispiel von Upsun Cloud veranschaulicht dies.
5. Verschiebe Geheimnisse und Umgebungskonfigurationen in die Variablen der Hosting-Plattform.
6. Migre die Daten. Exportiere sie, importiere sie in die neue Datenbank und teste anschließend eine Wiederherstellung.
7. Teste die gesamte App in einer Vorschauumgebung, bevor sie für Nutzer sichtbar wird.
8. Richte Überwachung und Warnmeldungen für Fehler und langsame Antworten ein.
9. Wechsle die Domain und halte die alte Bereitstellung noch einige Tage als Ausweichlösung verfügbar.

Auf Upsun Cloud ist dies eine einzige .upsun/config.yaml-Datei, die die App, ihre Datenbank und ihre geplanten Jobs definiert

Wo sollte eine mit Vibe programmierte App laufen?

Die richtige Umgebung hängt davon ab, wie stark die App gewachsen ist. Für manche Apps ist es eine gute Wahl, auf dem Builder zu bleiben.

Upsun Cloud eignet sich für Teams, die alle Apps, Datenbanken und Umgebungen an einem Ort haben wollen – über die von ihnen gewählten cloud-Regionen hinweg. Die Plattform verfügt über Zertifizierungen nach ISO 27001, SOC 2 Typ 2, PCI DSS Level 1 und HIPAA. 

Kann man nach dem Launch weiterhin mit KI entwickeln?

Ja. Der Übergang in die Produktivumgebung verändert nur, wo die App läuft – nicht, wie schnell ihr programmieren könnt. Programmier-Agenten wie Claude Code können Upsun-Projekte über den Upsun-Skill und den Upsun-MCP-Server bereitstellen und überprüfen.

Für Teams sorgt Upsun Dispatch für Struktur bei dieser Arbeit. Es wandelt ein Issue in einen Pull-Request um, wenn jemand mit @upsun-dispatch implement kommentiert, hält an menschlichen Kontrollpunkten für Entscheidungen an und protokolliert jeden Lauf, einschließlich Plan, Genehmiger und Kosten. 

Häufig gestellte Fragen

Muss ich eine „Vibe-codierte“ App neu programmieren, um sie in der Produktivumgebung zu verwenden?

Die meisten mit „Vibe“ programmierten Apps müssen nicht neu geschrieben werden. Sie benötigen eine Überprüfung, ein Git-Repository, die Auslagerung von Geheimnissen und Umgebungskonfigurationen aus dem Code sowie eine Hosting-Einrichtung mit backups, Überwachung und Testumgebungen.

Ist Programmieren in KI-App-Baukästen sicher?

Code, der in KI-App-Baukästen programmiert wird, ist standardmäßig nicht sicher. Die häufigsten Probleme sind fehlende Regeln für den Datenbankzugriff und im Browser sichtbare API-Schlüssel. Sicherheitsscans der Baukästen helfen zwar, aber bei Apps, die personenbezogene Daten oder Zahlungsdaten verarbeiten, ist immer noch eine manuelle Überprüfung erforderlich.

Kann ich meinen KI-Builder nach der Migration weiter nutzen?

Ja, wenn der Builder mit Git synchronisiert ist. Du kannst weiterhin im Builder bearbeiten, Änderungen in dein Repository pushen und von dort aus bereitstellen.

Kann eine mit „Vibe-Code“ programmierte App echten Datenverkehr bewältigen?

Viele mit „Vibe“ programmierte Apps bewältigen echten Datenverkehr problemlos. Die Hosting-Kapazität ist selten die erste Grenze. Die üblichen Grenzen liegen beim sicheren Testen von Änderungen, bei der Datenwiederherstellung und bei der Zusammenarbeit im Team.