Replit-app werkt in preview maar niet na publiceren? Een checklist voor founders

Je test de app in Replit, stuurt iemand de link en hoort meteen dat inloggen, opslaan of afrekenen niet werkt. Voordat je Agent vraagt die functies opnieuw te bouwen, loop je deze Replit-checklist voor productiedeployments door. Een verschil tussen de twee omgevingen kan de fout verklaren zonder dat er een nieuwe implementatie nodig is.

Waarom kan een app in de Replit-preview werken en live falen?

De Replit-preview en de gepubliceerde app zijn gescheiden omgevingen. De live app kan een andere URL, configuratie, data en runtimegedrag hebben dan het project dat je aan het bewerken bent.

De publicatiehandleiding van Replit legt uit dat publiceren een productiedeployment aanmaakt en dat latere bewerkingen die pas veranderen na een nieuwe publicatie. Controleer dus eerst of je de bedoelde release test. Noteer de publieke URL, het tijdstip van de laatste publicatie, de actie die faalt en of de fout ook optreedt in een nieuwe browsersessie.

Verzamel niet vijf losse screenshots om Agent vervolgens te vragen de hele app te repareren. Kies één fout: bijvoorbeeld dat een nieuwe klant een foutmelding krijgt na het klikken op Opslaan. Noteer het verwachte resultaat, het daadwerkelijke resultaat en het tijdstip. Dan heb je iets concreets om te vergelijken met de logs van de gepubliceerde applicatie.

Gebruikt de app het juiste deploymenttype?

De deployment moet het soort programma ondersteunen dat je app draait. Een set statische bestanden en een full-stack applicatie stellen verschillende eisen aan hosting.

Per oktober 2026 onderscheidt de documentatie over deploymenttypes van Replit Autoscale-, Static-, Reserved VM- en Scheduled-deployments. Controleer het deploymenttype onder de Publishing-instellingen en vergelijk het met wat de applicatie werkelijk nodig heeft.

Dezelfde documentatie vermeldt dat Static niet compatibel is met apps die met Replit Agent zijn gemaakt, omdat die apps een backend nodig hebben. Laat een developer de build- en run-commando's controleren als de applicatie is aangepast. Een grotere machine kopen lost geen ontbrekende serverroute of verkeerd opstartcommando op.

Zijn de benodigde productiesecrets echt beschikbaar?

Controleer de credentials en configuratie die de gepubliceerde app gebruikt, inclusief hun namen en de omgeving waarvoor ze bedoeld zijn. Dat een sleutel tijdens het ontwikkelen beschikbaar is, bewijst niet dat de live integratie goed is geconfigureerd.

De Secrets-handleiding van Replit verwijst naar Publishing → Adjust settings → Production app secrets. Daarin wordt ook onderscheid gemaakt tussen gevoelige secrets en niet-gevoelige configuratiewaarden. Controleer daar de vereiste items, zonder hun waarden in een troubleshooting-prompt te kopiëren.

1. Vraag om een lijst van de vereiste variabelenamen, waar elke variabele wordt uitgelezen en of die tijdens de build of tijdens runtime wordt gebruikt.
2. Controleer of de productie-items exact overeenkomen met die namen en bij de juiste provideraccounts horen.
3. Houd servercredentials op de server; een frontendvariabele of browserbundle is geen opslagplek voor secrets.
4. Publiceer opnieuw als het platform of het buildproces dat vereist, en herhaal daarna de oorspronkelijke actie op de publieke URL.

Leest de gepubliceerde app de bedoelde database?

Stel vast welke database live wordt gebruikt voordat je ontbrekende productierecords als een kapotte interface behandelt. Voorbeelddata die je in development ziet, is mogelijk niet de data die de app van je klanten leest.

De handleiding over ontwikkel- en productiedatabases van Replit beschrijft gescheiden omgevingen en verschillende set-upstappen voor de huidige en de legacy-infrastructuur. Bekijk de productieselectie in de Database-tool en de publicatie-instellingen die voor jouw app gelden. Ga er niet van uit dat een tutorial voor een andere projectgeneratie op jouw project van toepassing is.

Neem een hypothetische directory-app. De preview toont tien bedrijven, maar de live site toont er geen. Controleer voordat je de lijstcomponent opnieuw bouwt of de productieomgeving goedgekeurde bedrijfsrecords bevat. Misschien ontbreekt er alleen een bewuste data-import of initialisatiestap. Kopieer alleen data die geschikt is voor live gebruik, en bescherm bestaande klantrecords vóór elke import of schemawijziging.

Bij een mislukte schrijfactie verzamel je de operatie en een opgeschoonde foutmelding. Vraag een developer om onderscheid te maken tussen een verbindingsfout, een ontbrekende tabel, een constraint of een autorisatieprobleem. Door de connection string steeds opnieuw te wijzigen kun je het oorspronkelijke probleem verhullen en per ongeluk ontwikkelwerk op de verkeerde data richten.

Werken bestanden en externe callbacks op het publieke domein?

Controleer waar geüploade bestanden worden opgeslagen en welk domein externe services aanroepen. Beide kunnen in een preview correct lijken, terwijl ze niet geschikt zijn voor de gepubliceerde applicatie.

Voor uploads biedt Replit App Storage persistente objectopslag. Bekijk de huidige implementatie in plaats van aan te nemen dat bestanden die naar een runtimemap worden geschreven de persistentie en toegangscontrole hebben die je product nodig heeft. Test na een gecontroleerde release het uploaden, ophalen en afschermen van een bestand.

Controleer voor inlogproviders, betaalwebhooks en e-maillinks bij de betreffende provider de toegestane origins, geregistreerde endpoints en return-URL's. Waar nodig moeten die naar het bedoelde gepubliceerde domein verwijzen. Test de volledige round trip: je app verlaten, de actie bij de provider afronden en terugkeren op een bruikbaar scherm.

Houd een kleine integratie-inventaris bij: service, omgeving, publiek callbackpad, naam van het secret en verantwoordelijke persoon. De inventaris bevat configuratiefeiten, geen secretwaarden. Zo zijn latere domeinwijzigingen en overdrachten veel makkelijker te controleren.

Hoe verifieer je de reparatie live?

Reproduceer de oorspronkelijke actie op de publieke URL en bekijk daarna het bijbehorende bewijs in productie. Een geslaagde publicatie betekent dat de release is afgerond; het bewijst niet dat elke klantflow werkt.

De Monitoring-handleiding van Replit legt requeststatussen, responstijd, resourcegebruik en applicatielogs uit. Gebruik het tijdstip van de mislukte actie om je onderzoek af te bakenen. Hoog resourcegebruik en een applicatiefout zijn verschillende bevindingen, dus stel eerst een diagnose voordat je de capaciteit aanpast.

1. Gebruik een nieuw account op het gepubliceerde domein en herhaal exact de flow die faalde.
2. Controleer na het vernieuwen van de pagina of het bedoelde record of de verwachte integratie-uitkomst bestaat.
3. Bekijk het bijbehorende serverrequest of de logregel en test daarna veilig een verwant foutscenario.
4. Herhaal de belangrijkste flow op een telefoon en controleer of het gedrag dat eerder werkte nog steeds werkt.

Wat als de deployment toch nog ontwikkelwerk nodig heeft?

Als de configuratiecontroles de fout niet oplossen, baken het ontwikkelwerk dan af rond de specifieke grens die kapot is. Zorg voor een reproductie, de deploymentinstellingen, opgeschoonde foutmeldingen en een overzicht van de betrokken services.

Gebruik de bredere productiechecklist voor AI-MVP's voordat je je publiek uitbreidt, of de gids over de fix-loop als herhaalde prompts regressies veroorzaken. Wil je hulp bij het reviewen en uitbrengen van de volgende versie, plan dan een gesprek over je Replit-app. Samen bepalen we of je een configuratiereparatie, een gerichte codewijziging of een groter releaseplan nodig hebt.