Mettiamo l’applicazione su un server che controlliamo, con pubblicazione reversibile, copie di sicurezza verificate e un punto in cui si vede quando qualcosa è caduto.

Dove scegliete, e verifichiamo che sia davvero lì. I nostri sistemi si trovano su OVHcloud, Bucarest e su Microsoft Azure, Poland Central, entrambi nello Spazio Economico Europeo, e la posizione è stata confermata interrogando il servizio di metadati della macchina virtuale e il registro dell’indirizzo — non leggendo la documentazione del fornitore. La verifica conta: per un trasferimento all’interno dello Spazio Economico Europeo, il capitolo sui trasferimenti della Legea 195/2024 non si applica e non sono necessarie autorizzazioni speciali. Al di fuori di esso, compare un dossier di garanzie.

Non sempre. Una piattaforma gestita è la scelta corretta quando il team è piccolo, il traffico è irregolare e nulla nello stack ha requisiti di residenza. Il server proprio diventa l’argomento migliore in tre situazioni: quando i dati devono restare in una determinata giurisdizione, quando il costo diventa imprevedibile su scala, e quando volete poter prendere tutto e andarvene. Abbiamo fatto anche la migrazione inversa per un sistema proprio: da un database ospitato negli Stati Uniti a uno stack self-hosted nell’Unione Europea, con otto container — database, autenticazione, interfaccia REST, tempo reale, storage, metadati, pannello e porta di accesso.

Si fa rollback, e preferibilmente da sola. La versione precedente resta sul disco accanto a quella nuova, e dopo la pubblicazione un controllo richiede la pagina reale e conferma che il file servito sia quello appena costruito; in caso contrario, lo script torna automaticamente indietro. Dove usiamo il passaggio atomico del collegamento simbolico, il rollback è una sola operazione. Non è una descrizione da brochure — il meccanismo ha già intercettato una pubblicazione con un pacchetto vecchio rimasto nella directory di lavoro del runner e l’ha annullata.

Ogni giorno dove l’abbiamo costruita — e lo sottolineiamo, perché una copia automatica non appare da sola quando si sposta un’applicazione su un server. La copia parte a un’ora fissa, viene recuperata al boot successivo se la macchina era spenta, e se l’esportazione esce vuota l’esecuzione è trattata come fallimento. La copia parte anche fuori dalla macchina, in una regione dell’Unione Europea, con replica, versioning, eliminazione reversibile e scadenza automatica. Il test di ripristino fa parte della consegna: una copia mai ripristinata è un’ipotesi, non una copia.

Dipende da cosa abbiamo costruito, e vale la pena dirlo senza abbellimenti. I controlli di salute a livello di container e i punti di stato delle applicazioni esistono; l’allarme verso un canale di messaggistica, con limitazione di frequenza, esiste dove lo abbiamo costruito. Un punto di verifica dello stato che nessuno interroga non è monitoraggio — è una pagina. Se volete vero monitoraggio, è una fase separata, con un osservatore esterno che interroga periodicamente e con un destinatario dell’allarme che può essere svegliato.

No, ed è una decisione presa consapevolmente, non una svista. La catena di pubblicazione costruisce e copia il codice; e basta. Le modifiche di schema sono file versionati nel repository, applicati manualmente, con una copia di backup fresca dietro, e i componenti che mantengono lo schema in memoria vengono riavviati dopo. Una migrazione applicata automaticamente in produzione da un processo che non sa cosa c’è nella tabella è il modo abituale in cui si perdono dati in modo irreversibile.

Attraverso tre regole. Le azioni esterne sono fissate sull’impronta completa del commit, non sull’etichetta — a marzo 2026 un’azione usata su larga scala è stata reindirizzata dalle sue etichette verso codice malevolo e ha raggiunto oltre 23.000 repository in 24 ore. La copia di lavoro non conserva credenziali. La pubblicazione non avviene con una chiave di accesso memorizzata nella piattaforma di codice, ma tramite un esecutore proprio che gira sulla macchina di destinazione, con diritti concessi puntualmente. Riconosciamo che non tutti i nostri progetti più vecchi rispettano ancora tutte e tre; la loro migrazione è un lavoro a sé.

Sì, e il primo passaggio è sempre un inventario, non una modifica. Cosa gira effettivamente, sotto quale supervisore, con quali versioni, quali porte sono esposte, quali copie di sicurezza esistono, se qualcuna è mai stata ripristinata, quali segreti sono finiti nei repository e in che misura la configurazione nel repository assomiglia ancora al file sul server. L’ultima verifica produce quasi sempre qualcosa: abbiamo documentato, in un progetto proprio, un file di configurazione modificato direttamente in produzione, che ha lasciato accanto una copia di backup con timestamp.

Andate via del tutto. L’infrastruttura sta fin dall’inizio sui vostri account presso il fornitore, e la consegna include il repository con tutte le configurazioni del server, la procedura di pubblicazione e di rollback, la procedura di ripristino testata e l’elenco delle attività programmate con ciò che fa ciascuna. Il blocco contro la cancellazione accidentale del gruppo di risorse di produzione viene impostato fin dall’installazione. Se un fornitore condiziona la vostra uscita alla riscrittura dell’infrastruttura, quello era il problema, non la tecnologia.