Aruba e il deploy da incubo: 11 tentativi falliti in un giorno (e cosa ho imparato)

Il 15 giugno 2026 ho passato una giornata intera a rilasciare la versione 2.3 di uomodicasa.it — un sito React con decine di pagine prerenderizzate e tool nel browser (compressore immagini, QR code, PDF). Il codice era pronto. Il problema era Aruba: hosting economico, niente SSH, solo FTP vecchio stile.

Risultato del conto: 11 tentativi di deploy falliti, 2 riusciti, una pagina bianca a metà serata e la certezza che «hosting italiano low cost» e «sito moderno con molti file» non convivono bene senza pazienza — o senza cambiare piano.

Qui sotto ti racconto cosa è successo in italiano umano. Se gestisci un sito su Aruba (o stai per farlo), forse ti risparmio una domenica buttata.

Perché non è stato un semplice «carica i file»

Su Serverplan o su un VPS apri SSH, lanci rsync o uno script, controlli e hai finito. Su Aruba, sul piano base che uso per uomodicasa.it, non c’è SSH. L’unica strada è il FTP: protocollo degli anni ’90, lento, capriccioso, che su Aruba ha regole sue.

Il sito da pubblicare non è un index.html e basta: sono 224 file — HTML per ogni sezione, decine di chunk JavaScript (i pezzi in cui il codice del sito viene diviso e che il browser carica uno alla volta), librerie OCR, regole .htaccess. Ogni file è un punto dove qualcosa può rompersi.

Ne ho già parlato in generale in Aruba pro e contro e sui prezzi al rinnovo. Questo è il racconto di una giornata reale, non di teoria.

Mappa della giornata (semplificata)

Il flusso è stato questo — dall’alto verso il basso, come una cascata di problemi:

Fase 1 — GitHub Actions: quattro colpi a vuoto

Avevo configurato il deploy automatico: ogni push su GitHub, build del sito, upload via FTP su Aruba. Bello sulla carta. In pratica, il 15 giugno, quattro run consecutive fallite una dopo l’altra.

Errore 1: la build non partiva nemmeno

Sul mio PC Windows la build passava. Sui server Linux di GitHub no: il modulo che gestisce il banner cookie (GDPR) va importato in un certo modo, e lì il sistema non trovava una funzione che sul mio computer risultava disponibile. Stesso codice, ambiente diverso — e la compilazione si fermava prima ancora di caricare qualcosa su Aruba. Traduzione: quello che compili in casa non è detto che compili in cloud.

Errore 2 e 3: il file «mangiato» a metà

Qui la cosa si fa interessante — e tipica di Aruba FTP.

Il compressore immagini del sito pesa circa 112 kilobyte di JavaScript. Dopo l’upload, sul server ne arrivavano 16 kilobyte. Non un errore evidente: il deploy sembrava verde, ma il file era troncato. Il browser carica mezzo programma e implode.

Ho provato a ricaricare quel file a mano, più volte, con script diversi. Stesso risultato. È lo stesso problema che avevo già visto in passato con altri chunk — non è un caso isolato.

Nota: sì, avrei potuto caricare quel file a mano dal pannello di controllo Aruba — e a volte lo faccio. Ma non mi piace dover tenere due strade per pubblicare lo stesso sito: una automatica che fallisce e una manuale di ripiego. Succede anche con le immagini: si troncano e tocca rimetterle a posto una per una. Se vai a vedere, su uomodicasa.it la favicon è ancora tronca — segno che il problema non è finito con quel deploy.

Errore 4: il comando giusto su Windows, sbagliato su Ubuntu

Un altro fix ha introdotto un comando FTP che su Windows va bene e sui runner GitHub no (lftp -f non supportato). Morale: CI + FTP Aruba = fragile, soprattutto con IP dei server GitHub che cambiano sempre (e Aruba spesso vuole whitelist IP).

A quel punto ho spento il deploy automatico su push. Da oggi il rilascio lo faccio solo dal PC, con uno script dedicato.

Fase 2 — Sei tentativi dal computer di casa

Senza SSH non puoi sincronizzare cartelle come fanno i professionisti. Devi entrare in FTP, cartella per cartella, file per file. Aruba poi ha una regola fastidiosa:

Non puoi caricare un file scrivendo il percorso completo (tipo about/index.html). Devi prima entrare nella cartella about, poi caricare index.html.

Sembra banale. Il mio script, per creare le cartelle, finiva per entrare due volte nella stessa directory — e Aruba rispondeva con un errore del tipo «non esiste la cartella about/about». Sei tentativi, stesso muro, finché non ho capito che la libreria FTP entrava già nella cartella e io la facevo entrare un’altra volta.

Altri scivoloni della serata:

• Password FTP scritte in .env.example invece che in .env — lo script non partiva nemmeno.
• Oltre 200 file da caricare uno a uno: circa 90 secondi a deploy, quando va bene.
• Verifica post-upload: controllo che ogni file JavaScript sul server pesi quanto quello locale (altrimenti è troncato).

Al settimo tentativo: 224 file su 224, versione 2.3 online, dimensioni corrette. Ho tirato un sospiro di sollievo. Troppo presto.

Fase 3 — «Il deploy è ok ma il sito sparisce»

Apri uomodicasa.it: vedi header, articoli, footer per un secondo. Poi tutto bianco. Classico incubo: il server ha i file giusti, ma il JavaScript lato browser va in crash e svuota la pagina.

Causa: un fix fatto al mattino per far passare la build su GitHub aveva rotto l’import dei cookie nel browser. Il file caricato era perfetto; il codice dentro no. FTP non ti dice nulla su questo — devi aprire la console del browser.

Una riga corretta, un rebuild, un ottavo deploy. Fine giornata. Sito su.

Cosa significa per te (senza fare il sysadmin)

Se senti dire…	Cosa può voler dire su Aruba shared
«Il sito è lento»	Piano condiviso + sito pesante; spesso serve ottimizzare prima di cambiare hosting.
«Il deploy automatico non va»	FTP + IP variabili + tanti file = alto rischio. Deploy manuale o hosting con SSH.
«Funziona su metà pagine»	File JavaScript troncati in upload: sembrano ok ma sono corrotti.
«Pagina bianca dopo l’aggiornamento»	Upload riuscito ≠ sito funzionante. Serve test nel browser, non solo «file caricati».
«Non ho SSH»	Sei legato a FTP o al pannello. Per siti moderni è un limite serio.

Cosa farei io al posto tuo

1. Sito vetrina WordPress leggero — Aruba può bastare, se ottimizzi immagini e plugin (ne parlo spesso nel blog WordPress).
2. Sito React / molti file / deploy frequente — valuta hosting con SSH (anche Serverplan, che uso per danielechiuri.it) o piano superiore Aruba con accesso shell.
3. Dopo ogni deploy — apri il sito, Ctrl+F5, prova le pagine importanti. Non fidarti solo del «deploy completato».
4. Password FTP — mai nel repository Git; solo file locale ignorato da git.

Non è un manifesto anti-Aruba: è un caso reale. Aruba per dominio + email + sito semplice resta conveniente. Aruba per questo tipo di progetto, con questo flusso di lavoro, oggi mi ha fatto perdere una giornata intera.

In sintesi

• 11 deploy falliti, 2 riusciti, in un solo giorno.
• GitHub Actions + FTP Aruba: combinazione fragile.
• File troncati a ~16 KB: sintomo da tenere d’occhio.
• Deploy «verde» ≠ sito che funziona: serve smoke test nel browser.
• Senza SSH sei prigioniero del FTP — e Aruba non è il FTP più docile del mondo.

Stai valutando Aruba per un progetto nuovo, o hai già un sito che «ogni tanto fa i capricci» dopo un aggiornamento? Scrivimi — in una call si capisce se il problema è il piano, il sito o il modo in cui viene pubblicato.