Manuale: target di deployment e il tuo dominio

Distribuire sul tuo server significa dare a un agente un accesso di tipo SSH a una macchina che stai pagando, su cui potrebbero già trovarsi altre cose. È un livello di fiducia diverso rispetto a pubblicare su un sottodominio gratuito, e la configurazione lo riflette — pochi campi, compilati una volta sola, e poi ogni build successivo è un pulsante. Ecco cosa chiedono davvero le persone prima e dopo averne configurato uno.

Cosa mi serve per creare un target?

Cinque cose, in Impostazioni → Deploy:

1. Un nome che riconoscerai in seguito — "prod-vps", "client-hostgator", qualunque cosa sopravviva a un menu a tendina alle 23
2. Host e porta
3. Credenziali SFTP
4. Un percorso webroot

Nessun token API, nessuna CLI da installare sul server, nessun cron job da tenere d'occhio. Se il tuo host offre accesso SFTP — il che copre praticamente ogni hosting condiviso, ogni VPS, ogni box WordPress gestito — hai finito in circa due minuti.

Password o chiave?

Chiave, se il tuo host la supporta. Le password funzionano bene e le salviamo con ambito limitato al tuo account, ma una chiave è un segreto in meno in giro — la differenza tra "revocare una chiave" e "reimpostare una password ovunque quella password sia stata riutilizzata" se qualcosa va storto in seguito. Molte configurazioni SFTP di hosting condiviso economico offrono solo l'autenticazione via password, e va bene lo stesso. Basta non riutilizzare quella password altrove.

Come trovo il percorso webroot giusto?

Questo è il campo su cui le persone sbagliano la prima volta, perché la risposta sbagliata sembra comunque plausibile. Non è la tua home directory, non è /var/www — è la cartella esatta da cui il tuo web server è configurato per servire i contenuti.

Se non sei sicuro, metti un file usa e getta test.txt nella cartella che pensi sia quella giusta usando un qualsiasi client SFTP, poi verifica se si carica su yoursite.com/test.txt. Se sbagli, il deploy riporterà comunque un successo — l'agente scrive fedelmente i file nella cartella sbagliata, e ti ritrovi a fissare un sito live che non è cambiato, chiedendoti perché.

Un target può coprire più di un dominio?

Sì, ed è questa la parte che fa risparmiare tempo reale una volta superato il primo sito. Un target è un server e un insieme di credenziali — non è legato a un singolo dominio. In Gestione domini colleghi ogni dominio a un target con un proprio override del webroot. Gestisci tre siti su un unico VPS con blocchi server Nginx?

• site-a → /var/www/site-a
• site-b → /var/www/site-b
• site-c → /var/www/site-c

Un target, tre collegamenti. Non stai reinserendo una password SSH tre volte, e non stai mantenendo tre target quasi identici che finiscono per disallinearsi il giorno in cui ruoti una chiave e ne dimentichi uno. Clicca su deploy su uno qualsiasi dei tre domini e sa già quale server e quale cartella usare — non scegli mai al momento del deploy.

Cosa fa davvero l'agente quando si connette?

Prima di tutto, si guarda intorno — in sola lettura, senza scrivere nulla ancora. Quell'ispezione verifica:

• Una cartella vuota
• Una versione precedente di questo stesso build
• Una vecchia installazione WordPress
• Un placeholder "coming soon" che il tuo host ha messo lì di default

Questo decide la strategia. Un webroot vuoto riceve un semplice upload. Un webroot con già qualcosa dentro viene gestito con più cautela, perché molte configurazioni reali hanno cose che convivono con il sito e che non dovrebbero sparire:

• A .well-known cartella per la validazione SSL
• Una uploads directory che nessuno ha mai messo in git
• A wp-config.php che nessuno vuole toccare

Il compito qui è più simile a "capire cosa è cambiato e riconciliarlo" che a "cancellare e sostituire".

Poi, prima che venga sovrascritto anche un solo byte, il webroot esistente viene catturato come versione sul tuo stesso host. Non un record in un database, non un diff calcolato e sperato corretto — uno snapshot reale di ciò che c'era davvero. Questo conta soprattutto al primissimo deploy su un target qualsiasi, perché quel deploy va sempre a finire sopra qualcosa, anche se quel qualcosa è il nulla. Cartella vuota, snapshot vuoto. Sito statico di cinque anni fa che nessuno ricorda di aver creato — preservato esattamente, gratis, prima di essere toccato. Ed è anche il deploy di cui sei meno sicuro, quindi è quello in cui questo conta di più.

Carica il mio codice sorgente o il sito compilato?

Il sito compilato, sempre. Per un sito statico sono le pagine generate. Per una build basata su framework — Next.js, Vite, qualunque cosa richieda il tipo di sito — è l'output compilato, la cartella dist oppure build , mai l'albero dei sorgenti. Credo sia la scelta giusta anche se significa che non puoi collegarti via SSH ed eseguire npm run dev su ciò che c'è sul server. Caricare i sorgenti significherebbe che il tuo webroot di produzione ha bisogno di un runtime Node e di una toolchain di build solo per servire HTML — trasformando un hosting condiviso mai pensato per eseguire una pipeline di build in uno che lo fa, e trasformando ogni deploy in "speriamo che il server abbia abbastanza memoria per completare npm install". Distribuire solo l'output compilato mantiene il webroot esattamente com'è previsto da un server di file statici. Noioso. Ed è proprio ciò che vuoi alle 2 di notte quando qualcosa non va e stai fissando quella cartella cercando di capire cosa viene davvero servito.

Come faccio a sapere se un deploy ha davvero funzionato?

Dopo l'upload, l'agente raggiunge l'URL live e verifica se risponde correttamente — non un 500, non una pagina vuota. Qualunque cosa trovi, più tutto ciò che ha notato durante l'ispezione su cui vuole il tuo parere ("questo webroot ha una cartella wp-content che ho lasciato intatta, confermi che va bene così?"), finisce nella chat thread della build. Questo è lo schema di tutta la piattaforma: nessun successo silenzioso, nessun fallimento silenzioso che finisce in un ticket di supporto. L'agente ti dice cosa ha visto e cosa ha deciso, nello stesso thread in cui hai richiesto la build.

Cosa contiene esattamente la cronologia delle versioni?

Ogni deploy aggiunge una versione — non solo il primo. Quindi la cronologia non è la sequenza delle tue build su una timeline astratta; è la sequenza letterale di ciò che è stato servito da quel webroot, in ordine, a partire da qualunque cosa ci fosse prima del tuo arrivo. La versione uno è sempre quello stato pre-piattaforma, catturato automaticamente. Non devi pensarci.

Cosa ripristina esattamente il rollback?

La versione live precedente, esattamente — non una nuova esecuzione di una vecchia build, non un'approssimazione. I file reali che stavano servendo il traffico prima. È una garanzia decisamente più solida rispetto alla maggior parte delle funzioni di "rollback" che ho usato altrove, che di solito significano "rideploya da un vecchio commit" e danno per scontato, silenziosamente, che il tuo processo di build sia deterministico e che il tuo ambiente non sia cambiato nel frattempo. Qui il rollback è il ripristino di uno snapshot noto e funzionante, ed è per questo che è sicuro usarlo sotto pressione — non devi chiederti se il rollback si comporterà diversamente da ciò che sta ripristinando.

E il momento in cui ti serve davvero non è mai tranquillo; è "la nuova build ha rotto il checkout e il traffico è live proprio adesso".

Un clic, versione precedente ripristinata, fatto. Il ragionamento dietro al trattare questa come una funzione di primo livello e non un ripiego è spiegato in Iterare senza paura — vale la pena leggerlo una volta, prima che ti serva. Sia la cronologia che il controllo di ripristino si trovano nella build card e nella vista cronologia del target.

Questo esegue il backup anche del mio database?

No, e preferisco dirlo chiaramente piuttosto che lasciare che qualcuno lo dia per scontato. La cronologia delle versioni sull'host copre ciò che questa pipeline di deploy ha inserito nel webroot. Se il tuo sito ha un database, upload degli utenti, o qualsiasi altra cosa che cambia al di fuori dei deploy, è una questione completamente separata — il rollback non la tocca e non va confuso con una strategia di backup che la copre.