Come esportare e ospitare da sé un'app creata con l'AI

Per ospitare da sé un'app creata con l'AI, porta fuori il codice (un download o una sincronizzazione con un repository GitHub di tua proprietà), ricrea i suoi segreti come variabili d'ambiente, sposta o ricrea il suo database, e distribuiscila su un host adatto a ciò che l'app è: un host statico per un front end semplice, oppure una piattaforma che esegue server o container per tutto ciò che ha un back end. Il codice è di solito la parte facile. Dati, segreti e i servizi che il builder gestiva in silenzio per te sono dove sta il lavoro.

Perché esportare

Ci sono buone ragioni per portarsi dietro il proprio codice, e alcune meno buone.

Buone ragioni:

• Proprietà e tutela. Una copia del codice nel tuo repository ti protegge se il builder cambia prezzi, funzionalità o condizioni.
• Passaggio a sviluppatori. Un team di ingegneri vorrà il codice in Git, negli strumenti e nel processo di revisione che usa abitualmente.
• Requisiti specifici. Residenza dei dati, un particolare provider cloud, policy di sicurezza aziendali o infrastrutture che il builder non offre.
• Scala o costi, a una dimensione in cui gestire la propria infrastruttura conviene davvero.

Ragioni meno buone: spostare un'app piccola con una manciata di utenti per risparmiare una cifra mensile modesta. Ospitare da sé sposta il lavoro su di te — aggiornamenti, backup, monitoraggio, patch di sicurezza. Può essere la scelta giusta; falla solo consapevolmente.

Una via di mezzo sensata: continua a costruire e ospitare dove sei, ma sincronizza con il tuo repository GitHub fin dall'inizio. Ottieni la tutela senza il lavoro operativo. Se Git ti è nuovo, leggi cos'è GitHub.

Cosa contiene e cosa non contiene un'esportazione

Prima di fare affidamento su un'esportazione, aprila e controllala. Di solito:

I segreti sono esclusi di proposito — un archivio che potresti inviare per email o committare non dovrebbe mai contenere chiavi attive. Le dipendenze sono escluse perché vengono ricostruite dal file di lock.

Passo 1: porta fuori il codice

Due vie comuni:

• Scarica un archivio del progetto. Rapido, va bene per un trasloco una tantum o per un backup.
• Sincronizza con GitHub. Meglio per tutto ciò che è continuo: storia completa, facile da clonare ovunque, e la maggior parte degli host distribuisce direttamente da un repository GitHub a ogni push.

In entrambi i casi, clona o decomprimi il progetto su un computer (o su un ambiente di sviluppo cloud) e cerca un README. Se non c'è, chiedi all'AI del builder di scriverne uno prima di andartene:

Scrivi un README per eseguire questo progetto fuori da questa piattaforma: lo stack, le versioni di runtime richieste, i comandi di installazione e build, il comando di avvio e la porta, ogni variabile d'ambiente che il codice legge (nomi e scopo, senza valori), e come vengono eseguite le migrazioni del database.

Questo unico prompt fa risparmiare ore, perché obbliga a mettere per iscritto le parti implicite della configurazione.

Passo 2: eseguilo prima in locale

Prima di distribuire da qualche parte, dimostra che l'app gira da sola:

1. Installa il runtime indicato nel README — Node.js, Python, Java, .NET — in una versione corrispondente.
2. Installa le dipendenze (npm install, pnpm install, pip install -r requirements.txt, o l'equivalente).
3. Crea un file .env locale con le variabili d'ambiente, usando chiavi di test dove possibile. Tienilo fuori da Git. Cosa sono le variabili d'ambiente e i segreti spiega il concetto.
4. Punta a un database — un Postgres locale, o un database di sviluppo gratuito di un provider gestito.
5. Esegui le migrazioni, poi avvia l'app e prova i flussi principali.

Qualsiasi cosa si rompa qui si romperà anche su un host, ed è molto più facile fare debug sulla tua macchina. Sorprese comuni: un URL di anteprima del builder scritto nel codice, una variabile d'ambiente mancante che il builder iniettava automaticamente, oppure un servizio (archiviazione file, ridimensionamento immagini) che esisteva solo sulla piattaforma.

Passo 3: sposta i dati

Se l'app ha utenti reali, i dati contano più del codice.

• Esporta il database. Per Postgres, pg_dump produce un file che puoi ripristinare con pg_restore o psql nel nuovo database. Chiedi all'AI del builder di eseguirlo se non hai accesso diretto, e di spiegarti cosa ha prodotto.
• Sposta i file caricati. Se gli utenti hanno caricato immagini o documenti, si trovano in un'archiviazione oggetti separata dal database. Copiali nel nuovo storage (per esempio un bucket compatibile S3) e aggiorna gli URL salvati se includono il vecchio host.
• Pianifica il passaggio. Per un'app attiva, l'approccio semplice è una breve finestra di manutenzione: fermi le scritture, fai un'esportazione finale, la ripristini sul nuovo host, cambi il DNS, poi riapri. Scrivi prima ogni passaggio.
• Prova un ripristino in un database di prova prima del trasloco vero.

Se Postgres ti è nuovo, cos'è Postgres spiega le basi.

Passo 4: scegli dove ospitarla

Abbina l'host a ciò che l'app è. I nomi qui sotto sono esempi di provider noti in ciascuna categoria a settembre 2026, non una classifica; verifica le funzionalità e i prezzi attuali sui loro siti.

Ti serviranno anche:

• Un database gestito — molti host di app offrono Postgres, e servizi dedicati come Neon o Supabase lo forniscono da soli. Un database gestito vale la pena: backup e aggiornamenti sono compito di qualcun altro.
• Archiviazione di oggetti per gli upload, se l'app ne ha.
• Invio email, pagamenti e provider AI — di solito basta impostare le stesse chiavi API sul nuovo host.

Essendo onesti sui compromessi: gli host di piattaforma (le prime quattro righe) sono più rapidi da configurare e mantenere, ma offrono meno controllo e i costi possono salire con il traffico. Un server virtuale spesso costa meno a carico costante e resta sotto il tuo pieno controllo, ma sei tu a occuparti di patch, TLS, backup, monitoraggio e ripristino. Se nessuno nel team vuole questo lavoro, scegli una piattaforma. Per le basi di cosa comporta l'hosting, vedi cos'è l'hosting web.

Passo 5: distribuisci e passa

1. Collega il repository all'host, o invia un'immagine di container.
2. Imposta le variabili d'ambiente nella dashboard dell'host — tutte quelle del tuo README, con valori reali.
3. Imposta i comandi di build e di avvio e la porta. Molti host passano la porta in una variabile d'ambiente PORT; l'app deve mettersi in ascolto su di essa e su tutte le interfacce (0.0.0.0), non solo su localhost.
4. Esegui le migrazioni sul nuovo database.
5. Prova sull'URL temporaneo dell'host prima di toccare il DNS.
6. Aggiorna i servizi esterni che puntano al vecchio URL: webhook dei pagamenti, URL di redirect OAuth per il login, link nelle email, origini consentite.
7. Sposta il dominio aggiornando i record DNS verso il nuovo host. Come collegare un dominio personalizzato spiega i record.
8. Mantieni brevemente la vecchia distribuzione finché non sei sicuro, poi spegnila.

Il passo 6 è quello più spesso dimenticato: login e pagamenti che smettono di funzionare in silenzio dopo un trasloco di solito risalgono a un URL di callback che punta ancora al vecchio host.

Passo 6: prendi in carico le operazioni

Una volta che ospiti da te, le cose che il builder gestiva diventano tue. Come minimo: backup automatici del database con un ripristino testato, monitoraggio degli errori, avvisi di uptime, aggiornamento delle dipendenze e un elenco di chi ha accesso a ogni account. Come portare un prototipo AI in produzione approfondisce questo elenco.

Checklist dell'esportazione

• Codice in un repository di tua proprietà, con un README che copre esecuzione, build e variabili d'ambiente
• L'app gira in locale da un clone pulito
• Database esportato e ripristino testato; file caricati copiati
• Host scelto in base alla forma dell'app, più database gestito e archiviazione
• Tutte le variabili d'ambiente impostate con valori reali sul nuovo host
• Webhook, redirect OAuth e link nelle email aggiornati
• DNS spostato, vecchia distribuzione mantenuta brevemente, poi rimossa
• Backup, monitoraggio ed elenco degli accessi in essere

Esportare da Mythex

Su Mythex sei proprietario del codice che costruisci. Con il piano Pro puoi scaricare il progetto come archivio da Impostazioni progetto → Esporta, oppure collegare GitHub e fare push e pull sul tuo repository; i piani Free possono consultare il codice in sola lettura, ma non esportarlo né sincronizzarlo. I segreti e node_modules sono esclusi dalle esportazioni, quindi ricrea i segreti sul nuovo host. La documentazione descrive i passaggi in esportare ed eseguire altrove e GitHub, esportazione e importazione. Puoi anche continuare a ospitare su Mythex e usare la sincronizzazione GitHub solo come tua copia e via di passaggio; se ti sposti, annulla la pubblicazione dell'app su Mythex una volta che il nuovo host è attivo.

Domande