L’app Replit funziona in anteprima ma si rompe dopo la pubblicazione? Una checklist per founder

Provi l’app su Replit, mandi il link a qualcuno e ti senti dire subito che login, salvataggio o checkout non funzionano. Prima di chiedere ad Agent di ricostruire quelle funzionalità, usa questa checklist per il deployment in produzione su Replit. Una differenza tra i due ambienti può spiegare il problema senza bisogno di una nuova implementazione.

Perché un’app può funzionare nell’anteprima di Replit e fallire online?

L’anteprima di Replit e l’app pubblicata sono ambienti separati. L’app live può avere un URL, una configurazione, dei dati e un comportamento a runtime diversi rispetto al progetto che stai modificando.

La guida alla pubblicazione di Replit spiega che pubblicare crea un deployment di produzione e che le modifiche successive non lo cambiano finché non pubblichi di nuovo. Per prima cosa, assicurati di testare la release giusta. Annota l’URL pubblico, l’orario dell’ultima pubblicazione, l’azione che fallisce e se l’errore si verifica anche in una nuova sessione del browser.

Non raccogliere cinque screenshot scollegati per chiedere ad Agent di sistemare l’intera app. Scegli un solo errore: per esempio, un nuovo cliente riceve un errore dopo aver selezionato Salva. Annota il risultato atteso, quello effettivo e l’orario. Così hai qualcosa di specifico da confrontare con i log dell’applicazione pubblicata.

L’app usa il tipo di deployment giusto?

Il deployment deve supportare il tipo di programma che la tua app esegue. Un insieme di file statici e un’applicazione full-stack hanno requisiti di hosting diversi.

A ottobre 2026, la documentazione sui tipi di deployment di Replit distingue tra deployment Autoscale, Static, Reserved VM e Scheduled. Controlla il tipo di deployment nelle impostazioni di Publishing e confrontalo con le reali esigenze dell’applicazione.

La stessa documentazione afferma che Static non è compatibile con le app create con Replit Agent, perché queste app richiedono un backend. Se l’applicazione è stata personalizzata, fai verificare a uno sviluppatore i comandi di build e di avvio. Acquistare una macchina più potente non risolverà una route server mancante o un comando di avvio errato.

I secret di produzione necessari sono davvero disponibili?

Controlla le credenziali e la configurazione usate dall’app pubblicata, compresi i loro nomi e l’ambiente a cui sono destinate. Una chiave disponibile durante lo sviluppo non dimostra che l’integrazione live sia configurata correttamente.

La guida ai Secrets di Replit indica il percorso Publishing → Adjust settings → Production app secrets. Distingue inoltre i secret sensibili dai valori di configurazione non sensibili. Controlla lì le voci necessarie, senza copiarne i valori in un prompt di troubleshooting.

1. Chiedi l’elenco dei nomi delle variabili necessarie, dove viene letta ciascuna e se è usata in fase di build o a runtime.
2. Verifica che le voci di produzione corrispondano esattamente a quei nomi e appartengano agli account dei provider previsti.
3. Tieni le credenziali del server sul server: una variabile frontend o un bundle del browser non sono un archivio per i secret.
4. Ripubblica quando la piattaforma o il processo di build lo richiedono, poi ripeti l’azione originale sull’URL pubblico.

L’app pubblicata legge il database giusto?

Individua il database live prima di considerare i record mancanti in produzione come un’interfaccia rotta. I dati di esempio visibili in sviluppo potrebbero non essere quelli che legge l’app usata dai tuoi clienti.

La guida ai database di sviluppo e produzione di Replit descrive ambienti separati e percorsi di configurazione diversi per l’infrastruttura attuale e quella legacy. Controlla la selezione di produzione nello strumento Database e le impostazioni di pubblicazione applicabili alla tua app. Non dare per scontato che un tutorial pensato per una generazione di progetto diversa valga anche per la tua.

Prendi un’ipotetica app di directory. L’anteprima mostra dieci attività, ma il sito live non ne mostra nessuna. Prima di ricostruire il componente della lista, verifica se in produzione esistono record di attività approvati. Il lavoro mancante potrebbe essere un’importazione di dati intenzionale o un passaggio di inizializzazione. Copia solo dati adatti all’uso live e proteggi i record dei clienti esistenti prima di qualsiasi importazione o modifica dello schema.

Per una scrittura fallita, raccogli l’operazione e l’errore ripulito dai dati sensibili. Chiedi a uno sviluppatore di distinguere un errore di connessione da una tabella mancante, da un vincolo o da un problema di autorizzazione. Cambiare ripetutamente la stringa di connessione può nascondere il problema originale e indirizzare per errore il lavoro di sviluppo sui dati sbagliati.

File e callback esterne funzionano sul dominio pubblico?

Verifica dove vengono salvati i file caricati e quale dominio chiamano i servizi esterni. Entrambi possono sembrare corretti in anteprima pur non essendo adatti all’applicazione pubblicata.

Per gli upload, Replit App Storage offre uno storage a oggetti persistente. Esamina l’implementazione attuale invece di presumere che i file scritti in una cartella di runtime abbiano la persistenza e i controlli di accesso di cui il tuo prodotto ha bisogno. Prova a caricare, recuperare e limitare l’accesso a un file dopo un rilascio controllato.

Per provider di login, webhook di pagamento e link nelle email, controlla con il provider interessato le origini consentite, gli endpoint registrati e gli URL di ritorno. Dove richiesto, devono puntare al dominio pubblicato previsto. Testa l’intero percorso: l’uscita dalla tua app, il completamento dell’azione presso il provider e il ritorno a una schermata utile.

Tieni un piccolo inventario delle integrazioni: servizio, ambiente, percorso di callback pubblico, nome del secret e persona responsabile. L’inventario contiene informazioni di configurazione, non i valori dei secret. Rende molto più semplice verificare i futuri cambi di dominio e i passaggi di consegne.

Come verificare la correzione in produzione?

Riproduci l’azione originale sull’URL pubblico, poi esamina le evidenze di produzione corrispondenti. Una pubblicazione riuscita significa che il rilascio è stato completato; non dimostra che ogni flusso dei clienti funzioni.

La guida al monitoraggio di Replit spiega stati delle richieste, tempi di risposta, uso delle risorse e log dell’applicazione. Usa l’orario dell’azione fallita per restringere l’indagine. Un uso elevato delle risorse e un errore applicativo sono risultati diversi: fai la diagnosi prima di modificare la capacità.

1. Usa un account nuovo sul dominio pubblicato e ripeti esattamente il percorso che falliva.
2. Verifica che il record o il risultato dell’integrazione previsto esista dopo aver ricaricato la pagina.
3. Controlla la richiesta o il log del server corrispondente, poi testa in sicurezza un caso di errore simile.
4. Ripeti il percorso principale da smartphone e verifica che il comportamento che prima funzionava funzioni ancora.

E se il deployment richiede comunque lavoro di sviluppo?

Se i controlli di configurazione non risolvono il problema, delimita il lavoro di sviluppo attorno al punto specifico che si è rotto. Porta con te una riproduzione, le impostazioni di deployment, gli errori ripuliti dai dati sensibili e una mappa dei servizi coinvolti.

Usa la più ampia checklist per portare in produzione un MVP creato con l’AI prima di allargare il tuo pubblico, oppure la guida per uscire dal loop di fix se i prompt ripetuti stanno creando regressioni. Se ti serve aiuto per rivedere e rilasciare la prossima versione, prenota una call sulla tua app Replit. Capiremo insieme se ti serve una correzione della configurazione, una modifica mirata al codice o un piano di rilascio più ampio.