Come ospitare un'app Bolt.new sul tuo VPS

Un’applicazione sviluppata in ambiente di test tramite Bolt.new funziona correttamente nell'anteprima, ma la sua pubblicazione in un ambiente di produzione richiede il trasferimento dell'infrastruttura su un server dedicato o VPS.

In sintesi: l'hosting autonomo di un'applicazione creata con Bolt.new richiede l'esportazione o la sincronizzazione del codice sorgente, la scelta dell'ambiente di runtime idoneo, l'impostazione di un web server/reverse proxy, l'associazione dei record DNS del dominio e la configurazione del certificato HTTPS. I rischi principali risiedono nell'errata scelta della procedura di build, nell'esposizione non corretta delle porte di rete, in manovre di aggiornamento distruttive e nella mancanza di documentazione dell'architettura.

La natura dell'applicazione creata con Bolt.new

Bolt.new è una piattaforma di sviluppo assistita da intelligenza artificiale che genera codice per applicazioni web standard. Il server rappresenta l'ambiente di destinazione in cui l'applicazione deve essere eseguita, protetta e mantenuta operativa nel tempo.

A seconda delle specifiche del progetto, Bolt.new può generare:

• Siti statici: file HTML, CSS e JavaScript pre-compilati. In questo caso, il web server deve unicamente distribuire asset statici al client.
• Web app dinamiche (full-stack): progetti basati su framework quali Next.js, Remix, React/Vite o Node.js. Richiedono un processo applicativo attivo in background, in grado di gestire le richieste HTTP, comunicare con i database e riavviarsi in caso di errori.

La corretta individuazione dello stack generato da Bolt.new determina la modalità di esecuzione e le risorse necessarie sul server.

I prerequisiti per la pubblicazione

Prima di procedere al rilascio dell'applicazione in produzione, occorre predisporre quattro componenti architetturali:

1. Repository o codice sorgente: esportare il codice da Bolt.new verso un sistema di controllo versione (es. Git). Questo approccio consente di tracciare le modifiche e ripristinare le versioni precedenti in caso di errori.
2. Dimensionamento del server: allocare risorse di calcolo sufficienti (CPU e RAM). La fase di compilazione dei framework JavaScript moderni (build step) può richiedere picchi significativi di memoria. Per un'analisi dei requisiti hardware, consulta la guida su che dimensione di VPS serve per le tue esigenze.
3. Puntamento DNS del dominio: configurare i record DNS affinché il nome di dominio reindirizzi il traffico all'indirizzo IP del server. Per le indicazioni operative, consulta la nostra guida su come collegare un dominio al tuo server.
4. Cifratura SSL/TLS (HTTPS): installare un certificato di cifratura sul server per garantire connessioni sicure tra gli utenti e l'applicazione. Per la procedura di configurazione, consulta la guida su come ottenere HTTPS gratis sul tuo server.

Flusso di deployment e architettura di rete

Il processo standard di pubblicazione si articola in cinque fasi consecutive:

1. Importazione del codice sorgente sul server target o nell'ambiente di containerizzazione.
2. Installazione delle dipendenze di progetto (es. tramite npm install o pnpm install).
3. Esecuzione della fase di compilazione (build) per generare gli asset di produzione.
4. Avvio del processo applicativo tramite un gestore di processi (es. PM2, systemd o Docker).
5. Configurazione di un web server (es. NGINX) con funzione di Reverse Proxy per l'instradamento del traffico dalle porte pubbliche (80/443) alla porta interna dell'applicazione.

Gestione degli errori comuni

• **Errore 502 Bad Gateway**: si verifica quando il Reverse Proxy (NGINX) non riesce a comunicare con il processo applicativo sottostante. Indica solitamente che l'applicazione è in blocco, in arresto o in ascolto su una porta differente da quella configurata nel proxy.
• Variabili d'ambiente mancanti: l'applicazione richiede le credenziali utilizzate in fase di sviluppo (chiavi API, stringhe di connessione al database). Se tali variabili non vengono definite nel file di ambiente del server, l'applicazione mostrerà pagine bianche o errori di autenticazione durante l'uso.
• Containerizzazione: l'impiego di Docker consente di isolare l'applicazione e le sue dipendenze in un ambiente controllato. Per approfondire l'argomento, consulta la guida su Docker su un server per principianti.

Problemi frequenti nella fase post-rilascio

• Interruzione del servizio: se l'applicazione è avviata da una sessione utente temporanea anziché tramite un Process Manager, il servizio si interromperà alla disconnessione o al riavvio del server.
• Certificati SSL/TLS non validi o scaduti: la mancata configurazione del rinnovo automatico del certificato impedisce il caricamento sicuro del sito.
• Saturazione della memoria in fase di Build: durante gli aggiornamenti del codice, la compilazione può causare l'esaurimento della memoria RAM nei server con risorse limitate, provocando il blocco del processo.
• Assenza di procedure di rollback: la sovrascrittura diretta dei file di produzione in assenza di versionamento impedisce il ripristino rapido di una versione funzionante a seguito di un aggiornamento errato.

FAQ

È possibile ospitare un'applicazione generata da Bolt.new su un server VPS privato? Sì. Bolt.new produce codice web standard che può essere eseguito su qualsiasi server Linux provvisto del runtime necessario (es. Node.js), di un Reverse Proxy, dei record DNS e dei certificati HTTPS.

Docker è obbligatorio per l'hosting di un'applicazione Bolt.new? Non è obbligatorio. Docker è consigliato per standardizzare l'ambiente di esecuzione, ma un'applicazione JavaScript o un sito statico possono essere eseguiti direttamente sul sistema operativo del server.

**Cosa determina l'errore 502 Bad Gateway in un'applicazione Bolt.new?** L'errore indica che il web server d'ingresso (NGINX) non trova alcun processo attivo sulla porta di rete specificata. Occorre verificare che l'applicazione sia in esecuzione e che la porta configurata nel Reverse Proxy corrisponda a quella dell'applicazione.

È possibile ospitare più applicazioni Bolt.new sul medesimo server? Sì. È necessario associare a ciascun progetto un nome di dominio distinto, un'istanza di processo isolata, una porta di rete interna dedicata e un relativo certificato HTTPS.

La scorciatoia

Server Manager semplifica l'hosting e la gestione delle applicazioni web offrendo un'interfaccia centralizzata per la gestione di domini, certificati HTTPS, processi applicativi e container.

La gestione visiva dell'infrastruttura consente di isolare i vari progetti, prevenire conflitti sulle porte di rete ed evitare interruzioni del servizio dovute a certificati scaduti o a riavvii non gestiti del server.

Questo approccio garantisce la trasparenza della configurazione di produzione, facilitando le operazioni di manutenzione e aggiornamento nel tempo.

Considerazioni finali

L'hosting autonomo di un'applicazione Bolt.new richiede una struttura di rete chiara e ben definita.

La configurazione delle dipendenze, l'impostazione del Reverse Proxy, l'integrazione dei certificati HTTPS e la gestione continua dei processi trasformano un'anteprima di sviluppo in un'applicazione web stabile, protetta e pronta per la produzione.