Cos'è successo a Lovable

Cos'è e perché conta

Ad aprile 2026 The Register ha raccontato la segnalazione di un ricercatore su Lovable, e Lovable ha poi spiegato l'incidente sul suo blog: tra febbraio e aprile, per un problema nel suo backend, chat e codice dei progetti pubblici potevano essere visti da altri utenti. Lovable dice che i progetti privati non sono stati toccati e che il problema è corretto. Se hai un progetto lì, leggi il loro post.

Non ce l'ho con Lovable. Questa storia mi ha solo ricordato quanto conta sapere dove vive il tuo progetto e chi tiene le sue chiavi. Se vive dentro una piattaforma, la sicurezza della piattaforma è la tua. Se vive in una cartella tua, con le chiavi tue, gli errori sono tuoi, e almeno li puoi correggere.

Il punto è che un progetto non è solo il codice: ci sono i dati, gli account degli utenti, i file caricati, le chiavi, il dominio. Ogni pezzo esce da una porta diversa, e se ne dimentichi uno te ne accorgi quando un utente non riesce più a entrare.

Qui sotto c'è come tirare fuori tutto. Uso i menu di Lovable, ma la logica vale per qualsiasi piattaforma. E serve anche se resti: avere una copia tua è buon senso.

Una regola prima di tutto: non cancellare nulla finché il nuovo non funziona.

1. Il codice

Su Lovable: Project settings → Git → GitHub. Colleghi il tuo account e fai creare il repository: Lovable lo crea privato e lo tiene sincronizzato nei due sensi, quello che cambi in Lovable va su GitHub e viceversa.

La sincronizzazione segue un solo branch, di solito main. Finché è attiva, fai le prove su un branch a parte e non tocchi il progetto dentro Lovable.

Se il tuo piano ce l'ha, nello stesso menu c'è anche «Download codebase»: lo zip di tutto il codice. Buono come copia di sicurezza, ma non si aggiorna.

Poi cloni il repository sul tuo computer, dal pulsante «Code» della pagina del repo su GitHub. Da qui è una cartella tua.

2. Il database

Il codice porta la struttura del database, non i dati. La struttura sta nelle migration: file SQL, di solito nella cartella supabase/migrations, che ricreano tabelle, colonne e regole di accesso. I dati, cioè le righe vere, li esporti a parte.

Per schema e dati, con il backend integrato di Lovable (Lovable Cloud) usi l'export del database dalle impostazioni avanzate: More → Cloud → Overview → Advanced settings → Export data. Il link arriva per email. È un archivio di backup di Postgres, non un file SQL da incollare: si ripristina con pg_restore. Se invece hai la stringa di connessione del database, usi pg_dump. Su Supabase la stringa la trovi nel pulsante «Connect» della dashboard del progetto, e la sua guida usa il comando supabase db dump.

Lo importi in un Postgres o Supabase tuo, nuovo e vuoto.

3. Gli utenti

Gli account di login non viaggiano con le tabelle: se sposti solo i dati, gli utenti restano indietro.

L'export completo di Lovable Cloud invece li include, con le password salvate in forma cifrata. Se lo ripristini in un progetto Supabase, gli utenti tengono la loro password. Due cose però non passano: le sessioni, quindi tutti dovranno rifare il login, e le impostazioni dei metodi di accesso, tipo «Accedi con Google», che riconfiguri sul nuovo.

Se arrivi da un'altra strada e le password non si possono portare, prepara un'email di «reimposta la password» da mandare il giorno del cambio.

4. I file caricati

Foto, documenti, avatar: non sono nel database e non sono nel codice. Su Lovable Cloud li trovi in More → Cloud → Storage. Scaricali e ricaricali sul nuovo storage, in bucket (le «cartelle» dello storage) con gli stessi nomi.

Poi conta i file prima e dopo.

5. Le chiavi

Le variabili segrete non escono col codice né con l'export del database. E su Lovable i segreti non si possono rileggere, solo sostituire: il valore lo prendi dal servizio che te l'ha dato.

Fai la lista di tutte: database, API, pagamenti, email. Mettile nel tuo .env sul computer e nelle impostazioni del nuovo hosting. Le chiavi private non vanno mai nel codice né su git, e mai in una variabile che inizia con VITE_: quelle finiscono nel browser, quindi lì solo valori pubblici.

Poi rigenerale: chiavi nuove, vecchie revocate. Una chiave che resta valida su una piattaforma che non usi più è una porta lasciata aperta.

6. Dominio e login

Punta il dominio al nuovo hosting, seguendo le istruzioni di chi ti ospita. L'indirizzo lovable.app resta a Lovable e continua a mostrare l'ultima versione che hai pubblicato lì.

Poi aggiorna gli URL di redirect del login: l'indirizzo nuovo va aggiunto tra quelli autorizzati dal tuo sistema di login. Se usi «Accedi con Google» o simili, aggiorna anche lì. Se te lo dimentichi, il login si rompe proprio sul dominio nuovo.

Con Claude Code, dentro la cartella

Apri il terminale nella cartella del progetto e lancia Claude Code (cd nella cartella, poi claude). Legge i file da solo. Io gli do queste richieste, in quest'ordine.

Leggi questo progetto e fammi l'elenco di tutto quello che dipende dalla piattaforma da cui arriva: variabili, servizi, URL, funzioni sul server.

Questa è la tua mappa. Le funzioni sul server sono quelle che girano fuori dal browser: nei progetti Lovable con Supabase stanno di solito in supabase/functions e vanno pubblicate a parte sul nuovo backend.

La prossima l'aggiungo io: ti dà la lista delle chiavi del punto 5 senza doverle cercare a mano.

Fammi la lista di tutte le variabili d'ambiente che il progetto usa: dove vengono lette, quali finiscono nel browser e quali devono restare segrete. Non scrivere i valori.

Fallo girare in locale col mio database nuovo e dimmi cosa manca.

Qui vengono fuori le chiavi dimenticate e le tabelle vuote. Claude Code ti chiede il permesso prima di modificare file o lanciare comandi, a seconda della modalità di permessi che hai scelto: leggi cosa sta per fare prima di dire sì.

Controlla che nessuna chiave sia scritta nel codice o nella cronologia di git.

Se ne trova una nella cronologia, cancellare il file non basta: resta nei commit vecchi. Quella chiave la rigeneri, punto.

7. Pubblica, prova, poi spegni il vecchio

Quando in locale va tutto, pubblica su un hosting che controlli tu. Poi prova le cose che si rompono per prime:

1. Il login: entra con un account che esisteva già e creane uno nuovo.
2. Un caricamento file, e che si riapra.
3. I pagamenti, se li hai, in modalità test.

Solo allora spegni il vecchio.

Gli errori più comuni

• Cancellare il progetto vecchio appena hai il repository. Tienilo acceso finché sul nuovo login, file e pagamenti non funzionano.
• Pensare che il repository sia tutto il progetto. Il codice porta la struttura; dati, utenti, file e segreti escono ognuno per conto suo.
• Importare i dati in un database già usato. Parti da un Postgres nuovo e vuoto.
• Copiare le vecchie chiavi sul nuovo e chiuderla lì. Rigenerale e revoca quelle vecchie.
• Dimenticare gli URL di redirect. Aggiungi il dominio nuovo tra quelli autorizzati dal login prima di spostarlo.

Checklist

• Repository su GitHub, privato, clonato sul computer
• Struttura e dati nel nuovo database, vuoto prima dell'import
• Login provato con un account vecchio e uno nuovo
• File scaricati, ricaricati e contati
• Chiavi in lista, rigenerate, vecchie revocate
• Dominio e URL di redirect aggiornati
• Il vecchio spento per ultimo

Domande frequenti