Replit-App funktioniert in der Vorschau, aber nicht nach dem Veröffentlichen? Eine Checkliste für Gründer

Sie testen die App in Replit, schicken jemandem den Link und hören sofort, dass Login, Speichern oder Checkout nicht funktionieren. Bevor Sie Agent bitten, diese Funktionen neu zu bauen, gehen Sie diese Checkliste für das Replit-Produktions-Deployment durch. Ein Unterschied zwischen den beiden Umgebungen kann den Fehler erklären, ohne dass eine neue Implementierung nötig ist.

Warum kann eine App in der Replit-Vorschau funktionieren und live fehlschlagen?

Die Replit-Vorschau und die veröffentlichte App sind getrennte Umgebungen. Die Live-App kann eine andere URL, Konfiguration, andere Daten und ein anderes Laufzeitverhalten haben als das Projekt, das Sie gerade bearbeiten.

Replits Anleitung zum Veröffentlichen erklärt, dass beim Veröffentlichen ein Produktions-Deployment erstellt wird und spätere Änderungen es erst mit einer erneuten Veröffentlichung beeinflussen. Stellen Sie zuerst sicher, dass Sie das beabsichtigte Release testen. Notieren Sie die öffentliche URL, den Zeitpunkt der letzten Veröffentlichung, die fehlschlagende Aktion und ob der Fehler auch in einer frischen Browsersitzung auftritt.

Sammeln Sie nicht fünf zusammenhanglose Screenshots, um Agent dann zu bitten, die ganze App zu reparieren. Wählen Sie einen Fehler aus: zum Beispiel erhält ein neuer Kunde nach dem Klick auf Speichern eine Fehlermeldung. Halten Sie das erwartete Ergebnis, das tatsächliche Ergebnis und die Uhrzeit fest. So haben Sie etwas Konkretes, das Sie mit den Logs der veröffentlichten Anwendung abgleichen können.

Nutzt die App den richtigen Deployment-Typ?

Das Deployment muss zu der Art von Programm passen, die Ihre App ausführt. Eine Sammlung statischer Dateien und eine Full-Stack-Anwendung haben unterschiedliche Hosting-Anforderungen.

Stand Oktober 2026 unterscheidet Replits Dokumentation zu Deployment-Typen zwischen Autoscale-, Static-, Reserved-VM- und Scheduled-Deployments. Prüfen Sie den Deployment-Typ in den Publishing-Einstellungen und vergleichen Sie ihn mit dem, was die Anwendung tatsächlich benötigt.

Dieselbe Dokumentation weist darauf hin, dass Static nicht mit Apps kompatibel ist, die mit Replit Agent erstellt wurden, weil diese ein Backend benötigen. Lassen Sie einen Entwickler die Build- und Run-Befehle bestätigen, wenn die Anwendung angepasst wurde. Eine größere Maschine zu kaufen, repariert weder eine fehlende Server-Route noch einen falschen Startbefehl.

Sind die benötigten Produktions-Secrets tatsächlich verfügbar?

Prüfen Sie die Zugangsdaten und die Konfiguration, die die veröffentlichte App verwendet, einschließlich ihrer Namen und der vorgesehenen Umgebung. Ein Schlüssel, der während der Entwicklung verfügbar ist, beweist nicht, dass die Live-Integration korrekt konfiguriert ist.

Replits Secrets-Anleitung verweist auf Publishing → Adjust settings → Production app secrets. Sie unterscheidet außerdem zwischen sensiblen Secrets und nicht sensiblen Konfigurationswerten. Prüfen Sie dort die erforderlichen Einträge, ohne deren Werte in einen Prompt zur Fehlersuche zu kopieren.

1. Lassen Sie sich eine Liste der benötigten Variablennamen geben – wo jede gelesen wird und ob sie zur Build- oder zur Laufzeit verwendet wird.
2. Prüfen Sie, ob die Produktionseinträge exakt diesen Namen entsprechen und zu den vorgesehenen Anbieterkonten gehören.
3. Belassen Sie Server-Zugangsdaten auf dem Server; eine Frontend-Variable oder ein Browser-Bundle ist kein Ort für Secrets.
4. Veröffentlichen Sie erneut, wenn Plattform oder Build-Prozess es erfordern, und wiederholen Sie dann die ursprüngliche Aktion über die öffentliche URL.

Liest die veröffentlichte App die richtige Datenbank?

Ermitteln Sie die Live-Datenbank, bevor Sie fehlende Produktionsdatensätze für eine defekte Oberfläche halten. Beispieldaten, die in der Entwicklung sichtbar sind, sind nicht unbedingt die Daten, die die App Ihrer Kunden liest.

Replits Anleitung zu Entwicklungs- und Produktionsdatenbanken beschreibt getrennte Umgebungen und unterschiedliche Einrichtungswege für aktuelle und ältere Infrastruktur. Prüfen Sie die Produktionsauswahl im Database-Tool und die für Ihre App geltenden Publishing-Einstellungen. Gehen Sie nicht davon aus, dass ein Tutorial für eine andere Projektgeneration zu Ihrem Projekt passt.

Nehmen wir eine hypothetische Verzeichnis-App: Die Vorschau zeigt zehn Unternehmen, die Live-Seite keines. Bevor Sie die Listenkomponente neu bauen, prüfen Sie, ob die Produktion überhaupt freigegebene Unternehmensdatensätze enthält. Möglicherweise fehlt ein bewusster Datenimport oder Initialisierungsschritt. Kopieren Sie nur Daten, die für den Live-Betrieb geeignet sind, und sichern Sie bestehende Kundendatensätze vor jedem Import oder jeder Schemaänderung.

Bei einem fehlgeschlagenen Schreibvorgang halten Sie die Operation und die bereinigte Fehlermeldung fest. Bitten Sie einen Entwickler, einen Verbindungsfehler von einer fehlenden Tabelle, einem Constraint oder einem Berechtigungsproblem zu unterscheiden. Wer den Connection-String wiederholt ändert, kann das ursprüngliche Problem verschleiern und Entwicklungsarbeit versehentlich auf die falschen Daten richten.

Funktionieren Dateien und externe Callbacks auf der öffentlichen Domain?

Prüfen Sie, wo hochgeladene Dateien gespeichert werden und welche Domain externe Dienste aufrufen. Beides kann in der Vorschau korrekt wirken und trotzdem für die veröffentlichte Anwendung ungeeignet sein.

Für Uploads bietet Replit App Storage persistenten Objektspeicher. Prüfen Sie die aktuelle Implementierung, statt anzunehmen, dass Dateien in einem Laufzeitordner die Persistenz und Zugriffskontrollen haben, die Ihr Produkt braucht. Testen Sie nach einem kontrollierten Release das Hochladen, Abrufen und Einschränken einer Datei.

Bei Login-Anbietern, Zahlungs-Webhooks und E-Mail-Links prüfen Sie beim jeweiligen Anbieter die erlaubten Origins, registrierten Endpunkte und Rückleitungs-URLs. Sie sollten, wo nötig, auf die vorgesehene veröffentlichte Domain verweisen. Testen Sie den kompletten Ablauf: die App verlassen, die Aktion beim Anbieter abschließen und auf einen sinnvollen Bildschirm zurückkehren.

Führen Sie ein kleines Integrationsverzeichnis: Dienst, Umgebung, öffentlicher Callback-Pfad, Name des Secrets und verantwortliche Person. Das Verzeichnis enthält Konfigurationsfakten, keine Secret-Werte. Es erleichtert spätere Domainwechsel und Übergaben erheblich.

Wie sollten Sie die Reparatur live überprüfen?

Reproduzieren Sie die ursprüngliche Aktion über die öffentliche URL und prüfen Sie dann die zugehörigen Belege aus der Produktion. Eine erfolgreiche Veröffentlichung bedeutet, dass das Release abgeschlossen wurde – nicht, dass jeder Kunden-Workflow funktioniert.

Replits Monitoring-Anleitung erklärt Request-Status, Antwortzeiten, Ressourcennutzung und Anwendungs-Logs. Nutzen Sie den Zeitstempel der fehlschlagenden Aktion, um die Untersuchung einzugrenzen. Hohe Ressourcennutzung und ein Anwendungsfehler sind unterschiedliche Befunde – diagnostizieren Sie also, bevor Sie die Kapazität ändern.

1. Verwenden Sie ein neues Konto auf der veröffentlichten Domain und wiederholen Sie exakt den fehlgeschlagenen Ablauf.
2. Bestätigen Sie nach dem Neuladen der Seite, dass der erwartete Datensatz oder das Integrationsergebnis vorhanden ist.
3. Prüfen Sie den zugehörigen Server-Request oder Log-Eintrag und testen Sie dann gefahrlos einen benachbarten Fehlerfall.
4. Wiederholen Sie den Hauptablauf auf einem Smartphone und prüfen Sie, ob das zuvor funktionierende Verhalten weiterhin funktioniert.

Was, wenn das Deployment trotzdem Entwicklungsarbeit braucht?

Wenn die Konfigurationsprüfungen den Fehler nicht beheben, grenzen Sie die Entwicklungsarbeit auf die konkrete defekte Schnittstelle ein. Bringen Sie eine Reproduktion, die Deployment-Einstellungen, bereinigte Fehlermeldungen und eine Übersicht der beteiligten Dienste mit.

Nutzen Sie die umfassendere Produktions-Checkliste für KI-MVPs, bevor Sie Ihre Zielgruppe vergrößern, oder den Leitfaden zur Bugfix-Schleife, wenn wiederholte Prompts Regressionen erzeugen. Wenn Sie Unterstützung beim Prüfen und Ausliefern der nächsten Version möchten, buchen Sie ein Gespräch zu Ihrer Replit-App. Gemeinsam klären wir, ob Sie eine Konfigurationsreparatur, eine gezielte Codeänderung oder einen umfassenderen Release-Plan brauchen.