Ospitare un'applicazione creata con l'IA: da Lovable o Bolt al vostro server

Dove gira oggi la vostra applicazione

Lovable, Bolt e Replit pubblicano l'applicazione sulla propria infrastruttura, con un clic. Ecco che cosa dice la loro documentazione, consultata a ottobre 2026:

v0 pubblica su un progetto Vercel e genera un'applicazione Next.js (React, TypeScript, Tailwind CSS); il codice si esporta, o si sincronizza con GitHub nei due sensi. Cursor è un editor e un agente di programmazione installato sul vostro computer: il codice è già lì, e la scelta dell'hosting resta interamente vostra.

Questi hosting integrati sono pensati per pubblicare in fretta. Su Lovable come su Replit, la versione online è un'istantanea, rinnovata a ogni pubblicazione, e il costo segue l'uso della piattaforma (su Lovable, dei crediti coprono l'attività del back-end e l'IA; su Replit, il piano Starter comprende un'applicazione pubblicata, che scade dopo 30 giorni e va ripubblicata). Si passa a un server proprio per avere un dominio e dei dati sotto il proprio controllo, risorse riservate, attività in background permanenti o requisiti di conformità.

Recuperare il codice e i dati

La via più sicura è collegare il progetto a un repository GitHub: ogni modifica vi arriva come commit, con tutta la cronologia. Su Lovable, la sincronizzazione funziona nei due sensi: continuate a costruire in Lovable mentre il vostro server serve l'applicazione.

1. Lovable: collegate il progetto a GitHub, GitLab o Bitbucket, oppure scaricate l'archivio .zip del codice (abbonamento a pagamento).
2. Bolt: collegate GitHub, oppure cliccate sul titolo del progetto, in alto a sinistra, poi su «Download».
3. Replit: menu a tre puntini in cima all'albero dei file, poi «Download as zip»; oppure lo strumento Git, collegato al vostro account GitHub, con la sincronizzazione automatica.
4. v0: collegate GitHub dal menu del progetto («Settings», poi «GitHub»), oppure esportate il codice.

Il codice non contiene né il contenuto del database, né i file caricati dai vostri utenti. Su Lovable, il database si esporta dal progetto in un file .backup, da ripristinare con pg_restore, e i file dello storage si scaricano a parte. Su Bolt, il database può essere collegato al vostro account Supabase (piani Pro e Teams).

Di che cosa è fatta la vostra applicazione

Aprite il file package.json: dice su che cosa si basa l'applicazione, e quindi che cosa deve far girare il vostro server.

Con Vite, ogni variabile il cui nome comincia con VITE_ viene integrata nel codice inviato al browser, al momento del build: ogni visitatore può leggerla, e cambiarne il valore richiede un nuovo build. È voluto per la chiave pubblica di Supabase (sb_publishable_…, o la vecchia anon), fatta per il browser e protetta dalle regole di sicurezza a livello di riga (RLS). La chiave segreta (sb_secret_…, o la vecchia service_role) aggira queste regole: resta sul server, senza prefisso VITE_.

VITE_SUPABASE_URL=https://xxxx.supabase.co
VITE_SUPABASE_PUBLISHABLE_KEY=sb_publishable_xxxx
VITE_SUPABASE_PROJECT_ID=xxxx

Attivate RLS su ogni tabella prima della messa online: sono le sue regole a proteggere i vostri dati mentre la chiave pubblica circola nel browser.

Metterla sul vostro server, passo dopo passo

Su un VPS Linux, la messa online segue sempre lo stesso ordine. Lovable raccomanda Node.js 22 per compilare e far girare le sue applicazioni.

1. Il build: clonate il repository sul server, poi lanciate npm install e npm run build. Un'applicazione Vite produce file statici in dist/; un'applicazione TanStack Start si compila con NITRO_PRESET=node-server npm run build e si avvia con node .output/server/index.mjs, sulla porta 3000; un'applicazione Next.js si avvia con npm run start.
2. Il processo: per un'applicazione con server, un servizio systemd la avvia insieme alla macchina e la riavvia se si ferma.
3. Il server web: Nginx o Caddy riceve i visitatori. Per un'applicazione Vite, restituisce index.html per ogni indirizzo sconosciuto, altrimenti una pagina ricaricata risponde 404; per un'applicazione con server, inoltra le richieste al processo Node.js.
4. Il nome di dominio: un record DNS A (e AAAA per l'IPv6) punta al server.
5. L'HTTPS: un certificato Let's Encrypt, gratuito. Caddy lo ottiene e lo rinnova da solo; con Nginx, se ne occupa Certbot.
6. I segreti: in un file d'ambiente leggibile solo dall'utente dell'applicazione, fuori dal repository Git.
7. Il database: lasciate il back-end presso il suo fornitore, oppure installatelo sul vostro server. Un'applicazione Supabase ha bisogno, oltre al database PostgreSQL, dell'autenticazione, dello storage, del tempo reale e delle funzioni: Supabase self-hosted li riunisce.
8. Gli indirizzi di reindirizzamento: aggiungete il vostro dominio agli URL autorizzati dell'autenticazione, e presso Google o GitHub se il back-end cambia indirizzo.
9. I backup: il database e i file ogni notte, copiati fuori dal server, e un ripristino di prova di tanto in tanto.

app.votre-domaine.com {
	reverse_proxy 127.0.0.1:3000
}

server {
    server_name app.votre-domaine.com;
    root /var/www/app/dist;

    location / {
        try_files $uri $uri/ /index.html;
    }
}

Che cosa serve perché regga

Un'applicazione online è viva: le sue dipendenze ricevono correzioni, il suo database cresce, il suo traffico cambia. Ciò che la mantiene veloce e sicura sta in una routine:

Questa routine è il mestiere di un sistemista, e si può affidare. Con un VPS gestito, il provider tiene aggiornato il server, lo supervisiona giorno e notte e interviene senza attendere la vostra chiamata. Segue anche la vostra applicazione in modo proattivo (errori, rallentamenti, query costose, spazio su disco) e vi consiglia la correzione: la applicate con il vostro assistente IA, come avete costruito l'applicazione, e mantenete il controllo del vostro codice.