migrazione
Come migrare da Fly.io al tuo VPS
Un percorso di migrazione in parole semplici da Fly.io al tuo server, con rischi, ordine dei lavori e trappole di downtime spiegati chiaramente.
La tua applicazione è attualmente ospitata su Fly.io, ma hai la necessità di ottenere maggiore controllo, prevedibilità nei costi e un'architettura comprensibile senza dover consultare la documentazione specifica della piattaforma per ogni anomalia.
In sintesi: per migrare un'applicazione da Fly.io a un server proprietario, occorre ricostruire i servizi gestiti in precedenza dalla piattaforma: ambiente di esecuzione (runtime), connessioni al database, variabili d’ambiente, routing dei domini, certificati HTTPS, gestione dei log, procedure di backup e flussi di deployment. Il percorso più sicuro prevede la configurazione completa del nuovo server in parallelo all'infrastruttura esistente su Fly.io, il collaudo tramite un indirizzo temporaneo e l'aggiornamento dei record DNS solo a piena stabilità confermata.
Cosa cambia quando lasci Fly.io?
Fly.io non si limita all'esecuzione dell'applicazione, ma include un'infrastruttura complessa e ampiamente astratta.
Questo passaggio può essere paragonato al trasferimento da un immobile servito a un edificio di proprietà. Su Fly.io, servizi di rete, routing e gestione sistemistica sono integrati nella piattaforma. Su un server dedicato si ottiene il pieno controllo dell'ambiente, assumendo tuttavia la responsabilità diretta di configurazioni, sicurezza ed erogazione delle risorse.
La variazione principale risiede nella gestione operativa. Sebbene il codice sorgente dell'applicazione rimanga inalterato, le attività perimetrali diventano di tua competenza: riavvio automatico dei processi, instradamento del traffico, rinnovo dei certificati HTTPS, monitoraggio dello spazio disco e definizione di piani di backup testati.
| Area | Su Fly.io | Sul tuo server |
|---|---|---|
| Runtime dell’app | Gestito tramite Fly Machines | Processi di avvio e mantentimento definiti in autonomia |
| Rete | Instradamento automatico tra regioni | Puntamento diretto del dominio verso l'IP del server |
| HTTPS | Emissione e rinnovo automatizzati | Gestione e manutenzione dei certificati sul web server |
| Deployment | Integrato tramite strumenti Fly e fly.toml | Flusso di pubblicazione personalizzato e documentato |
| Operatività | Configurazioni di base astratte | Architettura da documentare e gestire direttamente |
Una migrazione da Fly.io non si riduce al semplice trasferimento di file, ma richiede la ricostruzione completa del contesto operativo in cui l'applicazione risiede.
Cosa dovresti spostare per primo?
Il primo passo consiste nel redigere un censimento dettagliato di tutte le dipendenze attive dell'applicazione su Fly.io.
L'analisi deve includere il codice sorgente, le versioni del runtime, le variabili d’ambiente, i secret, le stringhe di connessione ai database, i bucket di storage, i worker in background, i task pianificati, i domini personalizzati e le direttive presenti nel file fly.toml. Se utilizzi Docker per la containerizzazione, verifica che l'immagine possa essere eseguita al di fuori dell'ecosistema Fly.io senza dipendere da comportamenti specifici della piattaforma. Per un'introduzione ai concetti chiave dei container, consulta la guida Docker su un server per principianti.
Successivamente, definisci le specifiche hardware del server basandoti sui dati reali di utilizzo: consumo di memoria RAM, picchi di CPU, dimensioni del database e volume del traffico. Requisiti per un servizio leggero differiscono notevolmente da quelli necessari per un'applicazione con inteso utilizzo di risorse multimediali o database. Per criteri di scelta mirati, fare riferimento alla guida che dimensione di server ti serve.
Procedi secondo questo ordine sequenziale:
- Configura il server e le impostazioni di sicurezza di base.
- Ricrea l'ambiente di esecuzione dell'applicazione.
- Configura le variabili d’ambiente e i secret.
- Connetti o migra la base dati.
- Collauda l'applicazione su un indirizzo IP o sottodominio temporaneo.
- Attiva la cifratura HTTPS.
- Aggiorna i puntamenti DNS del dominio.
- Mantieni l'istanza Fly.io attiva fino a verifica conclusa.
Questo approccio garantisce la continuità del servizio attivo mentre si perfeziona il nuovo ambiente.
Come evitare downtime durante la migrazione?
Le interruzioni del servizio si verificano principalmente quando il dominio viene reindirizzato prima che il nuovo server sia completamente operativo.
I record DNS definiscono la destinazione del traffico di rete. Un aggiornamento prematuro rischia di instradare gli utenti verso un'infrastruttura non ancora configurata.
Prima di modificare i record DNS, esegui un collaudo completo sul nuovo server. Oltre alla homepage, verifica i flussi funzionali critici: procedure di autenticazione, invio dei moduli, elaborazione delle code in background, notifiche email, caricamento dei file ed esecuzione delle query al database. Controlla inoltre gli endpoint amministrativi, i webhook e i servizi di monitoraggio del sistema.
La configurazione della cifratura HTTPS richiede un'attenzione specifica. Un certificato SSL assicura la riservatezza delle comunicazioni e previene gli avvisi di protezione nei browser degli utenti. Per indicazioni operative sulla configurazione, consulta la guida come ottenere HTTPS gratis sul tuo server.
Per i database con operazioni di scrittura frequenti, occorre pianificare la sincronizzazione finale dei dati. Per progetti a basso traffico è sufficiente una breve finestra di manutenzione; per applicazioni ad alta frequenza di aggiornamento è opportuno prevedere meccanismi di replica o una procedura strutturata di cutover.
Infine, mantieni attiva l'infrastruttura su Fly.io per un periodo cuscinetto successivo allo switch. Poiché la propagazione dei record DNS avviene gradualmente, una parte degli utenti continuerà a raggiungere il vecchio server durante la transizione.
FAQ
È possibile riutilizzare l'immagine Docker creata per Fly.io? Nella maggior parte dei casi sì, a condizione che l'immagine non contenga dipendenze esclusive dall'architettura di Fly.io. È raccomandato un test di esecuzione sul nuovo server prima di reindirizzare il traffico.
È obbligatorio migrare contemporaneamente anche il database? Non è strettamente necessario. È possibile migrare l'applicazione mantenendo momentaneamente il database sulla posizione originaria, sebbene latenza di rete e policy di sicurezza rendano preferibile l'avvicinamento delle risorse.
L'indirizzo IP dell'applicazione subirà variazioni? Sì. Il passaggio a un server proprietario comporta l'assegnazione di un nuovo indirizzo IP pubblico a cui associare i record DNS del dominio.
Qual è il fattore di rischio principale durante la migrazione? La perdita o il disallineamento dei dati. È essenziale eseguire un backup completo di database e file persistenti prima dello switch definitivo e verificare preventivamente le procedure di ripristino.
La soluzione semplificata
Server Manager ti aiuta a strutturare la migrazione rendendo l'infrastruttura trasparente e di facile consultazione, evitando configurazioni estemporanee o non documentate. Il risultato è un sistema in cui domini, certificati HTTPS e processi applicativi rimangono definiti in modo chiaro e gestibile nel tempo.
Questo approccio previene le problematiche tipiche post-migrazione: puntamenti DNS errati, certificati SSL non validi, conflitti di configurazione tra ambienti o flussi di avvio dell'applicazione non documentati.
Il valore risiede nella leggibilità dell'infrastruttura: la gestione operativa e l'architettura del server rimangono chiare e governabili per qualsiasi intervento o manutenzione futura.
Com’è una buona migrazione?
Una migrazione da Fly.io eseguita correttamente si caratterizza per la sua continuità e linearità operativa.
L'infrastruttura originale rimane in funzione durante la fase di allestimento, il nuovo server viene collaudato accuratamente prima dell'aggiornamento dei DNS, la cifratura HTTPS viene attivata correttamente, la base dati viene messa in sicurezza e ogni componente architetturale risulta chiaramente identificata.
Il valore principale consiste nel raggiungere la piena sovranità della propria infrastruttura, all'interno di un ambiente ordinato, performante e pronto per sostenere gli sviluppi futuri.