Dein replit deploy wirkte erfolgreich — dann starb der Live-Link: leere Seite, 502 oder veralteter Build, während das Repl im Editor noch läuft.
Du hast Deploy geklickt, die URL geteilt. Besucher sehen Spinner, Fehlerseite oder die Version von gestern. Du hast zu GitHub gepusht und CI erwartet. Am öffentlichen Hostname änderte sich nichts. Der Agent sagte, Deployment sei bereit. Runtime-Secrets, DB-Ziel und SSL waren es nicht.
Was du siehst, wenn replit deploy tot ist
Symptome zeigen Deployment-Config, keine Zufallsbugs.
- 502 oder Application Error. Start-Command falsch, Crash beim Boot oder fehlendes Modul im Production-Image.
- Weißer Bildschirm auf Deploy-URL. Client baut, Env-Vars in Deployment-Secrets undefined.
- Daten live fehlen. App zeigt auf Dev-DB oder leeres Postgres, während der Repl Table Editor Zeilen hatte.
- Auth im Repl, scheitert auf Deploy-URL. Callback-URLs nutzen noch den Dev-Hostnamen.
- Git-Push änderte nichts Öffentliches. Kein Autoscale-Trigger oder Deploy scheiterte still im Tab.
- Custom Domain nicht sicher. DNS oder Zertifikat pending, während Default-Deploy-URL läuft.
Deploy-Logs mit Repl-Konsole vergleichen. Wenn Vorschau läuft und Deploy-URL nicht: Secrets und Connection Strings divergieren. Der replit database-Artikel, wenn Agent-Migrationen die Instanz löschten, die dein Deploy noch nutzt.
Warum replit deploy nach Git-Push scheitert
Replit trennt Editor-Runtime von Deployed-Runtime. Das Repl lädt Secrets aus dem Secrets-Panel für Development. Deployments lesen Deployment Secrets — eine separate Liste. Der Agent legt Keys in Dev an. Production sieht sie nicht, bis du jeden Namen kopierst.
Git-Push aktualisiert Repo-Dateien. Hosting, SSL und Autoscale-Deploy sind eigene Pipelines. Push ohne verknüpften Deploy-Flow lässt die alte Revision live. Nutzer beschuldigen Git, wenn der Deployments-Tab failed oder skipped zeigt.
DB-Connection-Strings unterscheiden sich. Dev nutzt vielleicht Replit-Postgres-URL. Deploy braucht den Production-String von Replit — oder externes Postgres. Agent-Seeds gegen Dev migrieren nicht automatisch zu Deploy.
Auth und OAuth folgen dem Hostnamen. Supabase- oder Replit-Auth-Allowlists müssen *.replit.app-Deploy-Host und Custom Domain enthalten. KI-Templates hardcoden REPL_SLUG-Dev-URLs.
Dasselbe Last-Mile-Muster wie lovable deploy: Code shippt, URLs und Secrets aktualisieren sich nicht von selbst.
Autoscale-Deploy legt Cold-Start- und Memory-Limits über Config-Lücken. Ein Repl, das im Editor sauber bootet, kann im Deployment an Memory scheitern, wenn der Agent schwere Dependencies draufpackte. Logs zeigen OOM oder Timeout — leicht als „Replit down“ misslesen, wenn der Fix schlankerer Start-Command oder weniger Pakete ist.
Static Deploy passt zu Frontends; Full-Stack-Node braucht den richtigen Deployment-Typ. Falsches Template shippt einen Build, der nie zu deinem lokalen Lauf passt.
Replit deploy Schritt für Schritt fixen
- Deployments im Repl öffnen. Letztes Production-Deployment finden. Status muss live sein, nicht failed oder superseded.
- Deploy-Logs lesen. Crash beim Start, fehlende Env oder Migrationsfehler notieren. Erste fatal Zeile fixen.
- Secrets nach Deployment Secrets kopieren. Jeden Namen, den die App liest: DB-URL, Session-Secret, API-Keys. Keine Tippfehler.
- Start-Command bestätigen. Static vs Autoscale vs Reserved VM — Framework treffen. Falscher Command endet sofort mit 502.
- DATABASE_URL auf Production-Daten zeigen. Table Editor oder externes Postgres mit Deploy abgleichen. Ausstehende Migrationen auf dieser Instanz nur nach Backup.
- Auth Redirect URLs aktualisieren. Deploy-Hostname und Custom Domain in Supabase oder Provider-Einstellungen.
- Nach Secret-Änderungen redeployen. Secrets hot-reloaden auf nicht allen Tiers. Erneut aus dem Tab deployen.
- Git-Push an Deploy hängen, wenn du CI willst. Autoscale vom Branch aktivieren oder nach Merge manuell deployen, bis Pipeline stabil ist.
- Custom-Domain-DNS und SSL fixen. Auf gültiges Zertifikat warten, bevor du die gebrandete URL teilst.
Nie Agent-Schema-Resets gegen die DB laufen lassen, die an deine Live-Deploy-URL hängt — ohne Export-Backup.
Checkliste, bevor du replit deploy vertraust
- Letzter Deployment-Status live mit aktuellem Zeitstempel
- Deploy-Logs zeigen sauberen Boot, keine Crash-Schleife
- Deployment Secrets spiegeln jedes Dev-Secret, das die App braucht
- DATABASE_URL zeigt auf die gewollte Production-Instanz
- Auth auf Deploy-URL im privaten Fenster erfolgreich
- Git-Push triggert neue Revision, wenn du auf CI setzt — im Tab verifizieren
- Custom Domain serviert HTTPS ohne Warnungen
- Ein Write und ein Read auf Live-Daten erfolgreich
FAQ
Warum ist mein replit deploy nach erfolgreichem Build tot?
Deployment nutzt getrennte Secrets und Runtime vom Repl-Editor. Fehlende DATABASE_URL, falscher Start-Command oder Auth-Callbacks noch auf dem Dev-Hostname — Production läuft Code, der Daten oder Session Store nicht erreicht.
Aktualisiert Git-Push automatisch replit deploy?
Nur wenn Autoscale oder Static Deploy an deinen Branch gehängt ist und der Build klappt. Push allein konfiguriert kein SSL, keine Custom Domains, keine Production-Env. Deployments-Tab auf die letzte Live-Revision prüfen.
Worin unterscheidet sich replit deploy von Lovable Publish?
Beide bringen Code auf eine öffentliche URL. Replit hält Compute und DB im selben Konto. Du musst trotzdem Deployment-Secrets setzen, Migrationen auf Production-DB laufen lassen und Auth-URLs angleichen — dieselben Last-Mile-Lücken wie bei lovable deploy.
