Pubblicazione · 6 min di lettura ·
Esportare un progetto Lovable o Bolt su GitHub: guida pratica
Come esportare un progetto Lovable, Bolt o Replit su GitHub e pubblicarlo su un altro hosting, senza dimenticare variabili, database e impostazioni.
Esportare un progetto Lovable su GitHub, o fare lo stesso con un'app creata con Bolt o Replit, è il modo più semplice per avere una copia del codice che resta tua, lavorarci con uno sviluppatore e, se vuoi, pubblicarla su un altro hosting. L'esportazione in sé richiede pochi minuti. La parte che sorprende molti è un'altra: il codice viaggia, ma impostazioni, chiavi e dati restano dove sono. In questa guida vediamo come esportare e cosa ricordarsi subito dopo.
GitHub in parole semplici
GitHub è un servizio online dove si conserva il codice dei progetti. Ogni progetto vive in un repository (o «repo»), una cartella che tiene traccia di tutte le versioni. Ogni salvataggio si chiama commit: una fotografia del codice in quel momento, con una breve descrizione di cosa è cambiato. Puoi immaginarlo come un archivio con la macchina del tempo: se qualcosa si rompe, puoi tornare alla versione di ieri.
Per usarlo basta un account gratuito. Non devi saper programmare per esportare il progetto, ma ti servirà capire un paio di concetti per non fare danni dopo.
Perché conviene esportare il progetto
- Backup: se la piattaforma ha un problema o chiudi l'abbonamento, il codice resta in un posto tuo.
- Collaborazione: uno sviluppatore può lavorare sul codice con i suoi strumenti, senza entrare nel tuo account.
- Hosting alternativo: puoi pubblicare l'app su servizi come Vercel, Netlify o su un server tuo.
- Meno dipendenza dalla piattaforma: è il primo passo per ridurre il cosiddetto lock-in, di cui parliamo nell'articolo su chi è il proprietario del codice di un'app creata con l'AI.
Come esportare un progetto Lovable su GitHub
Lovable non offre solo un'esportazione una tantum, ma una vera sincronizzazione con GitHub. Secondo la documentazione ufficiale, il collegamento si attiva dalle impostazioni del progetto (o del workspace), nella sezione dedicata a Git e GitHub. In sintesi:
- Nelle impostazioni del progetto apri la sezione Git / GitHub e aggiungi una connessione.
- Autorizza l'app di Lovable sul tuo account GitHub, o su quello della tua organizzazione.
- Crea un nuovo repository: Lovable ci copia il codice attuale.
Da quel momento la sincronizzazione va nei due sensi. Ogni modifica fatta in Lovable diventa un commit su GitHub, e le modifiche caricate su GitHub nel ramo principale tornano in Lovable. Un ramo (o branch) è una linea di sviluppo parallela del codice: per ora ti basta sapere che quello principale si chiama quasi sempre main.
È comodo, ma richiede una regola: non modificate lo stesso file contemporaneamente in Lovable e su GitHub, altrimenti rischiate conflitti difficili da sbrogliare. Secondo la documentazione, se rinomini il repository la sincronizzazione continua; se lo cancelli, si interrompe.
Come esportare un'app da Bolt o Replit
In Bolt, secondo il centro assistenza ufficiale, dal menu del progetto trovi l'opzione di esportazione: puoi scaricare il progetto come file ZIP oppure caricarlo direttamente su un repository GitHub. Se scegli lo ZIP, per averlo su GitHub dovrai poi creare un repository e caricarci i file.
Anche Replit offre strumenti per collegare il progetto a GitHub e per scaricare i file. I nomi delle voci cambiano spesso, quindi cerca nelle impostazioni o nel menu del progetto parole come «Git», «GitHub», «Export» o «Download».
Qualunque strada scegli, controlla subito il risultato su GitHub. Per un'app JavaScript devono esserci il file package.json (l'elenco delle librerie che l'app usa) e le cartelle con il codice, spesso src. Se mancano, l'esportazione non è completa.
Cosa viene esportato e cosa resta fuori
Questa è la parte più importante. Il repository contiene il codice, ma un'app online è fatta anche di impostazioni e dati che vivono altrove.
| Elemento | È su GitHub? | Dove si trova davvero |
|---|---|---|
| Codice dell'interfaccia e delle pagine | Sì | Nel repository |
| Struttura del database (tabelle, regole) | Spesso in parte, come file di migrazione | Nel servizio di database, per esempio Supabase |
| Dati degli utenti e contenuti | No | Nel database |
| File caricati (immagini, documenti) | No | Nello storage del servizio di backend |
| Variabili d'ambiente e chiavi segrete | No, e non devono esserci | Nel pannello della piattaforma o dell'hosting |
| Dominio personalizzato | No | Nel pannello DNS e nell'hosting |
| Impostazioni di login (redirect, provider) | No | Nel servizio di autenticazione |
Le migrazioni sono file che descrivono, passo dopo passo, come è stato costruito il database. Sono utili per ricrearlo, ma non contengono i dati: per quelli serve un'esportazione separata o un backup.
Lovable lo dice chiaramente nella sua documentazione: quando pubblichi fuori dalla piattaforma, i segreti configurati non vengono trasferiti e vanno reinseriti a mano sul nuovo hosting. Inoltre alcune funzioni restano legate a Lovable, come l'ambiente di anteprima e certi servizi gestiti direttamente da loro.
Ospitare l'app altrove: i passaggi
Una volta che il codice è su GitHub, pubblicarlo su un altro hosting è abbastanza lineare. Servizi come Vercel e Netlify possono importare direttamente un repository e ripubblicare l'app a ogni nuovo commit.
- Crea un account sull'hosting e importa il repository. Di solito il servizio riconosce da solo il tipo di progetto.
- Controlla le impostazioni di build. Per molti progetti generati con l'AI, basati su React e Vite, il comando è
npm run builde la cartella da pubblicare èdist: sono i valori che Lovable indica per i suoi progetti Vite. I progetti più recenti possono usare un framework con una parte che gira sul server, e in quel caso serve un hosting compatibile. - Inserisci le variabili d'ambiente. Copia nel pannello dell'hosting tutte quelle che l'app usa, con gli stessi nomi. Per un progetto Lovable con il backend integrato servono, per esempio,
VITE_SUPABASE_URLeVITE_SUPABASE_PUBLISHABLE_KEY. Tutti i dettagli nella guida sulle variabili d'ambiente. - Configura il routing. Se l'app è una single page application, serve una regola che faccia rispondere sempre
index.html, altrimenti le pagine interne danno 404 quando le ricarichi. - Avvia il deploy e leggi il log. Se la build fallisce, il log ti dice perché: trovi come interpretarlo nell'articolo sull'errore «Build failed» nel deploy.
- Aggiorna gli indirizzi autorizzati nel servizio di login, aggiungendo il nuovo dominio.
Ricorda che spostare il frontend (la parte visibile, che gira nel browser) non sposta il backend (la parte che gestisce dati e logica sul server). Il database resta dove si trova. Se vuoi portare via anche quello, è un progetto a parte, da pianificare con calma.
Attenzione alle chiavi nel repository
Prima di rendere pubblico un repository, o di condividerlo, controlla che non contenga chiavi segrete. Il file .env, dove spesso finiscono le chiavi, normalmente è escluso tramite .gitignore (un elenco di file da non caricare), ma non è sempre così. E a volte l'AI scrive le chiavi direttamente nel codice.
Se una chiave segreta finisce su GitHub, considerala compromessa: va revocata e sostituita con una nuova, come spieghiamo nella guida sulle chiavi API esposte. Nel dubbio, crea il repository come privato: potrai sempre renderlo pubblico più avanti, dopo un controllo.
Quando conviene farti aiutare
Esportare il codice è alla portata di tutti. Spostare su un altro hosting un'app già in uso, con utenti, dati e login attivi, è un'operazione diversa: bisogna ricreare le variabili, verificare il backend, aggiornare dominio e autenticazione e assicurarsi che niente si perda nel passaggio.
Se stai valutando di farlo, o se l'hai già fatto e qualcosa non torna, possiamo guardare insieme il repository e la configurazione e indicarti i passaggi nell'ordine giusto. Prenota una call gratuita di 20 minuti.
