Cos'è Fly.io e quando conviene

La tua applicazione gira in una regione sola, e per chi la visita dall'altra parte del mondo ogni richiesta è un viaggio intercontinentale di andata e ritorno. La risposta ovvia sarebbe "mettiamola anche là", ma sulle piattaforme normali è un progetto, non un'impostazione. Fly.io nasce esattamente su quel problema. In questo articolo trovi come funziona, cosa cambia rispetto a Railway e Render, e in quali casi la distribuzione geografica è una complicazione che non ti serve.

Cos'è

Fly.io è una piattaforma che prende il tuo container e lo fa girare su macchine virtuali leggere in una o più regioni del mondo, indirizzando ogni visitatore verso l'istanza più vicina a lui.

Il punto di partenza è lo stesso di altre piattaforme: hai un'applicazione, la impacchetti, la pubblichi e non tocchi un server. La differenza sta nell'unità di ragionamento. Su gran parte dei servizi gestiti pensi in termini di "un'applicazione su un'infrastruttura"; su Fly pensi in termini di "N macchine in M città".

Non è una piattaforma per siti statici e non compete con Cloudflare Pages o Vercel: quella è un'altra categoria. Fly fa girare processi, come Railway e Render, solo con un'idea diversa di dove vadano messi.

Il modello delle macchine

Sotto a Fly c'è una astrazione che si chiama Machine: una micro-VM che esegue il tuo container.

La cosa importante è quanto in fretta si accende e si spegne. Non è un container in un cluster sempre attivo, e non è nemmeno una VM classica che impiega un minuto ad avviarsi: è qualcosa in mezzo, pensato per passare da fermo a operativo in una frazione di secondo.

Questo permette un comportamento che altrove non esiste in questa forma: le macchine possono fermarsi quando non arriva traffico e riaccendersi alla prima richiesta.

# fly.toml
[http_service]
  internal_port = 8080
  force_https = true
  auto_stop_machines = "stop"
  auto_start_machines = true
  min_machines_running = 0

Con min_machines_running = 0 l'applicazione, quando nessuno la usa, non consuma. Alla prima richiesta la macchina riparte e serve la risposta — con un ritardo che c'è, ed è il prezzo onesto di questo modello.

Vale la pena essere chiari su cosa sia e cosa non sia. È più di una funzione serverless: la macchina, quando è accesa, è un processo normale, con il suo filesystem, le sue connessioni aperte, i suoi WebSocket e la possibilità di fare lavori lunghi. Ma è meno di un server sempre acceso: se la lasci scendere a zero, qualcuno paga la riaccensione.

Se metti min_machines_running = 1 hai un server normale che non si spegne mai, e il ritardo sparisce. Le due modalità coesistono: tipicamente una macchina sempre accesa nella regione principale e le altre che si alzano solo quando serve.

La distribuzione multi-regione

È la caratteristica centrale, e quella che giustifica l'esistenza del prodotto.

Aggiungere una regione è un comando:

fly deploy                        # pubblica l'applicazione
fly scale count 3 --region fra    # tre macchine a Francoforte
fly scale count 2 --region gru    # due a San Paolo
fly status                        # dove sta girando e in che stato

Da quel momento un visitatore europeo viene servito da Francoforte e uno brasiliano da San Paolo, senza che tu configuri un load balancer geografico o un DNS intelligente: l'instradamento lo fa la rete di Fly, che riceve la richiesta nel punto di ingresso più vicino e la consegna alla macchina più adatta.

Le applicazioni di un'organizzazione si parlano su una rete privata interna con nomi propri, quindi un servizio può chiamarne un altro senza passare da internet:

curl http://api.internal:8080/salute
curl http://fra.api.internal:8080/salute   # una regione specifica

L'avvertimento che conta più di tutto il resto

Distribuire l'applicazione in sei regioni non serve a niente se il database sta in una sola.

È l'errore concettuale più frequente e va detto prima dell'elenco dei vantaggi. Una pagina che fa quindici query verso un database dall'altra parte dell'oceano è più lenta se l'applicazione sta vicino all'utente, perché ogni query paga il viaggio intero: hai spostato il codice lontano dai dati e ogni round trip si è allungato. Il ragionamento completo è in cos'è l'edge computing, e vale identico per Cloudflare Workers.

La distribuzione geografica dà un beneficio reale in tre situazioni:

• I dati sono replicati anche loro, con repliche di lettura nelle stesse regioni dell'applicazione. Fly ha un meccanismo pensato per questo — le letture vanno alla replica locale, le scritture vengono reindirizzate alla regione primaria — ma l'applicazione deve essere scritta sapendolo.
• Le richieste sono poche e grosse. Una singola query per richiesta, o nessuna: lì la vicinanza all'utente si sente tutta.
• Il carico è di calcolo, non di dati. Elaborazione, rendering, inferenza: mettere la potenza vicino a chi la usa ha senso a prescindere.

Fuori da questi casi, una regione sola scelta bene è la configurazione giusta — e Fly resta comunque una piattaforma sensata su cui stare, semplicemente senza usare la sua caratteristica principale.

Il volume persistente

Un container è effimero per definizione: quello che scrivi nel filesystem sparisce al deploy successivo. Fly offre i volumi, dischi che restano attaccati a una macchina in una regione precisa.

fly volumes create dati --size 10 --region fra

[mounts]
  source = "dati"
  destination = "/data"

Serve per database gestiti da te, cache su disco, indici di ricerca, qualsiasi cosa debba sopravvivere al riavvio. Ma i vincoli vanno capiti, perché sono l'origine di brutte sorprese:

• Un volume vive in una regione e appartiene a una macchina. Non è uno storage condiviso: due macchine non vedono lo stesso volume. Se aggiungi regioni, ognuna ha il suo disco con dati diversi.
• Non è un backup. Ci sono istantanee, ma sono un'altra cosa da un backup verificato e portato fuori.
• Per i file degli utenti non è la scelta giusta. Caricamenti e allegati vanno su uno storage a oggetti come S3 o R2, che non è legato a una macchina.

Chi arriva qui per far girare un database sul volume deve sapere che si sta prendendo il mestiere di amministrarlo. Ha senso, ma è una scelta consapevole: l'alternativa è un database gestito come Neon, con il compromesso solito tra costo e tempo.

Fly, Railway e Render a confronto

Tutte e tre prendono un repository o un container e lo fanno girare senza che tu gestisca una macchina. La differenza è di posizionamento, non di categoria.

	Fly.io	Railway	Render
Unità di ragionamento	Macchine in regioni	Servizi in un progetto	Servizi gestiti
Multi-regione	Nativo, un comando	Regione singola	Regione singola
Come parte il deploy	Container / Dockerfile generato	Rilevamento automatico da Git	Rilevamento automatico da Git
Spegnimento a riposo	Sì, macchine che si fermano	Paghi la memoria occupata	Sospensione sul piano base
Disco persistente	Volumi per regione	Volumi	Dischi
Database gestito	Postgres gestito da te o servizio	Da un menu	Da un menu
Curva di apprendimento	Più alta: concetti propri	Bassa	Bassa
Strumento principale	CLI e fly.toml	Pannello web	Pannello web
Modello di prezzo	Risorse delle macchine accese	Consumo misurato	Piani a taglia

La sintesi onesta: Railway e Render sono più semplici, Fly è più capace e più esplicito. Su Fly la CLI e il file fly.toml sono il posto dove vivi davvero; su Railway e Render il pannello basta quasi sempre. Se hai una regione sola e nessuna esigenza particolare, Fly non ti dà niente in cambio della complessità in più.

Il paragone con un VPS è quello di sempre: a parità di risorse la macchina tua costa meno, e quello che compri qui è non doverla amministrare — il ragionamento per esteso è nel confronto dentro cos'è Railway.

Cosa fa perdere ore o soldi

Distribuire l'applicazione e lasciare il database in una regione. Il primo errore, già detto ma vale la ripetizione: misura la latenza reale prima e dopo, non fidarti dell'intuizione.

Dimenticare macchine accese. Aggiungi una regione per una prova, la prova finisce, la macchina resta lì a consumare. fly status una volta al mese evita fatture assurde.

Trattare i volumi come uno storage condiviso. Due macchine, due dischi, dati diversi: se non lo sai, scopri di avere metà dei caricamenti su una e metà sull'altra.

Aprire un pool di connessioni per macchina senza fare il conto. Dieci macchine con venti connessioni ciascuna sono duecento connessioni verso un database che magari ne regge un centinaio.

Non impostare i controlli di stato. Senza, una macchina malandata continua a ricevere traffico. Sono due righe in fly.toml e sono la differenza tra un guasto invisibile e un guasto gestito.

Portarsi dietro un'immagine enorme. Il tempo di deploy e di riaccensione dipende dalla dimensione del container: un'immagine costruita male rende lento tutto il modello. Vale quanto scritto in cos'è Docker sulle build a più stadi.

Quando conviene e quando no

Conviene se: hai utenti sparsi su più continenti e la latenza è un requisito dichiarato, non un desiderio; ti serve un processo vero — WebSocket, code, lavori lunghi — e non funzioni che vivono il tempo di una richiesta; lavori già a container e vuoi controllo su come e dove girano; hai bisogno di ambienti effimeri che si accendono e spengono spesso; vuoi un modello a costo prossimo a zero quando l'applicazione è ferma.

Non conviene se: i tuoi utenti stanno in un Paese solo — e questo copre la maggioranza dei progetti italiani; stai pubblicando un sito statico o prevalentemente frontend, dove le piattaforme dedicate fanno meglio; vuoi il percorso più breve possibile e il pannello web che fa tutto, perché lì Railway e Render sono più diretti; il carico è costante e prevedibile e il budget è stretto, dove un VPS gestito bene costa meno.

C'è anche il criterio meno tecnico e più utile: se leggendo la sezione sul multi-regione hai pensato "a me non serve", probabilmente Fly non è la tua piattaforma. La sua caratteristica principale non è un extra gratuito, è il motivo per cui accetti concetti in più.

In sintesi

Fly.io fa girare container su micro-VM che si avviano in fretta, in una o più regioni, con l'instradamento verso l'istanza più vicina fatto dalla rete.

Il multi-regione è la sua ragione d'essere, ed è anche la sua trappola: senza dati distribuiti, avvicinare l'applicazione agli utenti la allontana dal database e peggiora le cose.

Le macchine possono scendere a zero e riaccendersi, il che rende economici gli ambienti poco usati al prezzo di un ritardo sulla prima richiesta.

I volumi sono dischi legati a una macchina in una regione, non uno storage condiviso e non un backup.

Rispetto a Railway e Render è più potente e meno immediata: se ti basta far girare un backend in una regione, quelle due arrivano prima allo stesso risultato.

Per le alternative più semplici vedi cos'è Railway e cos'è Render; per capire quando la distribuzione geografica paga davvero, cos'è l'edge computing.