A face deploy pe propriul server înseamnă să oferi unui agent acces de tip SSH la o mașină pentru care plătești și pe care s-ar putea să existe deja alte lucruri. Acesta este un nivel de încredere diferit față de publicarea pe un subdomeniu gratuit, iar configurarea reflectă acest lucru — câteva câmpuri, completate o singură dată, iar apoi fiecare build ulterior devine un simplu buton. Iată ce întreabă de fapt oamenii înainte și după ce configurează o astfel de țintă.
De ce am nevoie pentru a crea o țintă?
Cinci lucruri, în Setări → Deploy:
- Un nume pe care îl vei recunoaște mai târziu — „prod-vps”, „client-hostgator”, orice supraviețuiește într-un meniu derulant la ora 23:00
- Gazdă (host) și port
- Credențiale SFTP
- O cale către webroot
Fără token-uri API, fără CLI de instalat pe server, fără job cron de supravegheat. Dacă gazda ta oferă acces SFTP — ceea ce acoperă aproape orice hosting partajat, orice VPS, orice server WordPress administrat — ești gata în aproximativ două minute.
Parolă sau cheie?
Cheie, dacă hostingul tău o suportă. Parolele funcționează la fel de bine și le stocăm asociate exclusiv contului tău, dar o cheie înseamnă un secret în minus lăsat pe undeva — diferența dintre „revocă o cheie” și „resetează o parolă peste tot unde a fost reutilizată aceeași parolă” dacă ceva merge prost mai târziu. Multe configurații SFTP ieftine de hosting partajat oferă doar autentificare prin parolă, și e în regulă și așa. Doar nu reutiliza acea parolă în altă parte.
Cum găsesc calea corectă a webroot-ului?
Acesta este câmpul pe care oamenii îl greșesc prima dată, pentru că răspunsul greșit tot pare plauzibil. Nu este directorul tău personal, nu este /var/www — este exact folderul din care serverul tău web este configurat să servească.
| Server | Webroot tipic |
|---|---|
| Apache / cPanel | public_html |
| Nginx | /var/www/mysite/html — sau o cale numită de un dezvoltator anterior acum trei ani, din motive pe care nimeni nu și le mai amintește |
Dacă nu ești sigur, pune un fișier de test test.txt în folderul pe care crezi că este cel corect, folosind orice client SFTP, apoi verifică dacă se încarcă la yoursite.com/test.txt. Dacă greșești aici, deploy-ul va raporta totuși succes — agentul scrie fidel fișierele în folderul greșit, iar tu rămâi să te uiți la un site live care nu s-a schimbat, întrebându-te de ce.
Poate o singură țintă să acopere mai multe domenii?
Da, iar aici economisești timp real după primul site. O țintă reprezintă un server și un set de credențiale — nu este legată de un singur domeniu. În Gestionarea domeniilor atașezi fiecare domeniu unei ținte, cu propria suprascriere de webroot. Rulezi trei site-uri pe un singur VPS cu blocuri de server Nginx?
site-a→/var/www/site-asite-b→/var/www/site-bsite-c→/var/www/site-c
O singură țintă, trei atașamente. Nu introduci de trei ori aceeași parolă SSH și nu întreții trei ținte aproape identice care se pot desincroniza în ziua în care rotești o cheie și uiți una dintre ele. Dai click pe deploy pentru oricare dintre cele trei domenii, iar sistemul știe deja ce server și ce folder să folosească — nu alegi nimic în momentul deploy-ului.
Ce face agentul de fapt când se conectează?
Mai întâi, se uită în jur — doar citire, nimic nu este scris încă. Această inspecție verifică:
- Un folder gol
- O versiune anterioară a acestui build exact
- O instalare veche de WordPress
- Un placeholder de tip „revenim în curând” pus acolo implicit de gazda ta
Asta decide strategia. Un webroot gol primește o încărcare directă. Un webroot cu ceva deja în el este tratat mai atent, pentru că multe configurații reale au lucruri care coexistă cu site-ul și care nu ar trebui să dispară:
- A
.well-knownfolder pentru validarea SSL - Un
uploadsdirector pe care nimeni nu l-a pus în git - A
wp-config.phppe care nimeni nu vrea să-l atingă
Sarcina este mai degrabă „identifică ce s-a schimbat și reconciliază” decât „șterge și înlocuiește”.
Apoi, înainte ca vreun byte să fie suprascris, webroot-ul existent este capturat ca versiune chiar pe gazda ta. Nu o înregistrare în bază de date, nu un diff pe care îl calculăm și sperăm că e corect — o captură reală a ceea ce se afla acolo. Acest lucru contează cel mai mult la primul deploy pe orice țintă, pentru că acel deploy se așază mereu peste ceva, chiar dacă acel ceva este nimic. Folder gol, captură goală. Un site static vechi de cinci ani pe care nimeni nu-și mai amintește că l-a construit — păstrat exact, gratuit, înainte de a fi atins. Acel prim deploy este și cel de care ești cel mai puțin sigur, așa că este cel unde acest lucru contează cel mai mult.
Încarcă codul sursă sau site-ul construit (build-ul)?
Site-ul construit, întotdeauna. Pentru un site static, acestea sunt paginile generate. Pentru un build de framework — Next.js, Vite, orice cere tipul de site — este rezultatul compilat, folderul dist sau build , niciodată arborele sursă. Cred că aceasta este decizia corectă, chiar dacă înseamnă că nu poți face SSH și rula npm run dev direct pe ce se află pe server. Încărcarea codului sursă ar însemna ca webroot-ul tău de producție să aibă nevoie de un runtime Node și un toolchain de build doar pentru a servi HTML — transformând o mașină de hosting partajat, care nu a fost niciodată concepută să ruleze un pipeline de build, într-una care o face, și transformând fiecare deploy în „speră că serverul are suficientă memorie ca să termine npm install." Livrarea doar a output-ului compilat menține webroot-ul exact ceea ce așteaptă un server de fișiere statice. Plictisitor. Plictisitor e ce vrei la 2 dimineața când ceva nu merge și te uiți fix la folderul respectiv încercând să-ți dai seama ce se servește de fapt.
Cum știu că un deploy chiar a funcționat?
După upload, agentul accesează URL-ul live și verifică dacă se rezolvă corect — nu 500, nu pagină goală. Orice găsește, plus orice a observat în timpul inspecției despre care vrea părerea ta ("acest webroot are un folder wp-content pe care l-am lăsat neatins, confirmă că e ok"), ajunge în firul de chat al build-ului. Ăsta e tiparul pe toată această platformă: fără succes tăcut, fără eșec tăcut care se transformă într-un tichet de suport. Agentul îți spune ce a văzut și ce a decis, în același fir de chat în care ai cerut build-ul.
Ce se află de fapt în istoricul versiunilor?
Fiecare deploy adaugă o versiune — nu doar primul. Deci istoricul nu este o reprezentare a build-urilor tale pe o cronologie abstractă; este chiar secvența literală a ceea ce a fost servit din acel webroot, în ordine, începând de la ce se afla acolo înainte să apari tu. Versiunea unu este întotdeauna starea de dinainte de platformă, capturată automat. Nu trebuie să te gândești la asta.
Ce restaurează de fapt revenirea (revert)?
Versiunea live anterioară, exact — nu o rulare din nou a unui build vechi, nu o aproximare. Fișierele reale care serveau trafic înainte. Aceasta este o garanție semnificativ mai puternică decât majoritatea funcțiilor de „rollback” pe care le-am folosit în altă parte, care de obicei înseamnă „redeployează dintr-un commit vechi” și presupun tacit că procesul tău de build este determinist și că mediul tău nu s-a modificat de atunci. Aici, revenirea este o restaurare a unei capturi cunoscute ca fiind funcțională, motiv pentru care este sigur să o folosești sub presiune — nu trebuie să te întrebi dacă rollback-ul s-ar putea comporta diferit față de lucrul la care revine.
Iar momentul în care chiar ai nevoie de asta nu este niciodată unul calm; este „noul build a stricat finalizarea comenzii și traficul e live chiar acum”.
Un click, versiunea anterioară restaurată, gata. Motivul pentru care tratăm acest lucru ca pe o funcție de prim rang, nu ca pe un detaliu secundar, este explicat în Iterarea fără teamă — merită citit o dată, înainte să ai nevoie de el. Atât istoricul, cât și controlul de restaurare se află pe cardul build-ului și în vizualizarea proprie de istoric a țintei.
Face backup și la baza de date?
Nu, și prefer să spun asta clar decât să las pe cineva să presupună altceva. Istoricul versiunilor pe gazdă acoperă ceea ce acest pipeline de deploy a pus în webroot. Dacă site-ul tău are o bază de date, încărcări de utilizatori sau orice altceva care se modifică în afara deploy-urilor, acesta este un subiect complet separat — revenirea nu îl afectează și nu trebuie confundată cu o strategie de backup pentru așa ceva.
