Cum alegem furnizorul de hosting pentru site-urile clienților noștri

Cel mai neplăcut telefon pe care îl primește o agenție sună așa: „nu mai merge site-ul”. E vineri la 17:40, clientul are o campanie activă, iar tu deschizi laptopul știind deja că problema nu e în cod. Codul era acolo și ieri.

Am avut conversația asta de destule ori cât să învățăm ceva simplu. Hostingul e o decizie pe care o iei o dată, la început, când pare doar o linie de cost, și o plătești în fiecare zi după aceea. Uneori în bani, mai des în ore și în nervi.

Construim site-uri de 14 ani și am livrat peste 400 de proiecte. O parte le administrăm și după lansare, ceea ce înseamnă că suportăm direct consecințele alegerii de hosting. Articolul ăsta e grila pe care o aplicăm înainte să recomandăm un furnizor, plus răspunsul la întrebarea pe care ne-o pune toată lumea la final: bun, și voi ce folosiți?

Pe scurt: cum alegem hostingul pentru clienții noștri

• Suntem o agenție de web development. Construim site-uri și administrăm o parte dintre ele după lansare, inclusiv partea de găzduire.
• Verificăm nouă lucruri înainte să recomandăm un furnizor: performanță, stabilitate, securitate, backup și restaurare, suport tehnic, migrare, compatibilitate cu WordPress, resurse pentru magazine online și scalare.
• Criteriul care ne-a costat cel mai mult când a lipsit nu e viteza. E timpul de restaurare dintr-un backup. Viteza se vede zilnic, restaurarea se vede o dată, într-o zi foarte proastă.
• Ce folosim noi: peste 180 de site-uri de clienți sunt găzduite la HostRiver, furnizor românesc de hosting cu datacenter propriu în Cluj-Napoca. Primul proiect l-am mutat acolo în 2020, iar din 2021 e alegerea noastră implicită.
• De ce acolo: suport pe ticket care răspunde și noaptea, un singur panou pentru tot portofoliul, și datele clienților în România, ceea ce scurtează discuțiile de conformitate.
• Recomandăm pentru site-uri de prezentare, site-uri de firmă, proiecte WordPress și magazine online mici și medii pe WooCommerce.
• Nu recomandăm pentru proiecte foarte mari, cu echipă internă de DevOps și nevoie de infrastructură definită în cod. Pentru astfel de clienți am lucrat pe AWS.
• Ce nu rezolvă niciun hosting: un site prost optimizat rămâne lent pe orice server.
• Transparență: suntem client HostRiver din 2020. Articolul nu e plătit și nu conține linkuri de afiliere.

Ce înseamnă, de fapt, să alegi un furnizor de hosting

Nu cumperi spațiu pe disc, cumperi un comportament la ore de vârf

Pagina de prețuri a oricărui furnizor vorbește despre spațiu, trafic și număr de site-uri. Sunt cele mai puțin interesante cifre din toată oferta. Un site de prezentare ocupă rar peste 2 GB, iar limita de trafic n-a fost o problemă reală pentru niciun client de-al nostru în ultimii ani.

Ce cumperi de fapt e comportamentul serverului atunci când lucrurile nu sunt normale. Când un client trimite newsletter la 40.000 de adrese și jumătate dintre ele deschid linkul în aceeași oră. Când un plugin prost scris intră în buclă. Când cineva îți scanează formularul de login cu zece mii de încercări pe minut.

În restul timpului, orice hosting pare bun.

Cine plătește o alegere proastă

Un hosting ieftin nu costă mai puțin, mută costul în altă parte. Îl mută în orele pe care le facturăm noi ca să diagnosticăm erori care nu țin de codul nostru, în comenzile pierdute cât site-ul e jos, și în timpul pe care proprietarul îl petrece explicând de ce nu merge.

Calculul pe care îl facem cu clientul e simplu și îl poți face și tu. Iei venitul lunar generat prin site, îl împarți la orele de activitate reală și afli cât te costă o oră de nefuncționare. Un magazin care face 50.000 de lei pe lună pierde, în medie, câteva sute de lei pe oră. În vârf de campanie, multiplicatorul nu mai e mediu: o oră proastă într-un Black Friday poate valora cât o săptămână obișnuită.

Cele trei tipuri de hosting și pentru cine sunt

Shared hosting înseamnă că site-ul tău stă pe un server împreună cu alte site-uri, iar fiecare cont are limite proprii de CPU, memorie și procese. E suficient pentru majoritatea site-urilor de prezentare, pentru bloguri și pentru magazine mici și medii. Aproximativ 80% din proiectele noastre rulează așa.

VPS înseamnă resurse rezervate doar pentru tine, pe o mașină virtuală, cu control la nivel de server. Îl folosim când un proiect depășește constant limitele contului sau când clientul are nevoie de o configurație specifică.

Server dedicat sau cloud propriu e altă categorie și apare rar în portofoliul unei agenții. Revin la ea în secțiunea despre AWS.

Criteriile pe care le verificăm înainte să recomandăm un hosting

Nu e o listă teoretică. E ce bifăm efectiv, în ordinea asta, când evaluăm un furnizor nou sau când un client ne întreabă dacă unde e acum e în regulă.

1. Performanța: ce măsurăm și ce ignorăm

Ignorăm scorul PageSpeed ca argument despre hosting. E un scor compus, influențat masiv de temă, de imagini și de scripturi terțe. Un site cu trei pixeli de tracking și un slider greu va avea scor prost pe orice server din lume.

Măsurăm TTFB, adică timpul până la primul byte primit de browser. E cifra care spune cât durează până când serverul începe să răspundă, înainte ca tema și imaginile să intre în ecuație.

Pe site-urile noastre servite din cache, TTFB-ul măsurat din România stă în general între 60 și 120 de milisecunde. Pe pagini care nu pot fi servite din cache, cum e coșul sau checkout-ul dintr-un magazin, e normal să urce la 250 până la 450 de milisecunde, pentru că acolo se execută efectiv PHP și interogări în baza de date.

Ce contează tehnic pentru cifrele astea: stocare NVMe în loc de SSD clasic, un server web optimizat pentru conținut dinamic și un strat de cache configurat corect. Pentru contextul complet despre ce înseamnă viteza pentru utilizator, documentația Google despre Core Web Vitals e sursa de referință.

2. Stabilitatea: ce poți verifica și ce nu

Nimeni nu poate promite onest un procent de uptime fără monitorizare. Nici noi nu scriem cifre pe care nu le-am măsurat.

Ce verificăm în schimb: există redundanță reală pe alimentare și pe răcire? Există un DNS cluster distribuit în locații separate, ca zona DNS să răspundă chiar dacă o locație pică? Datacenterul e construit după un standard recunoscut, sau e o cameră cu rack-uri și un aer condiționat?

Standardul la care se referă toată lumea e clasificarea Uptime Institute. Tier 3 înseamnă componente redundante și posibilitatea de a face mentenanță fără să oprești echipamentele. Nu e marketing, e o clasificare cu criterii publice.

Și punem monitorizare externă pe fiecare proiect pe care îl administrăm, cu verificare la un minut și alertă în Slack. Nu ne bazăm pe faptul că ne sună clientul.

3. Securitatea: ce trebuie să vină din partea hostingului

Împărțim securitatea în două. Ce ține de site, adică pluginuri actualizate, parole, drepturi, e treaba noastră. Ce ține de server trebuie să vină din partea furnizorului, altfel facem muncă de sysadmin pe bani de dezvoltare.

Cerem patru lucruri:

• Izolare între conturi. Un site compromis de pe același server nu trebuie să ajungă la fișierele tale. Tehnologia uzuală aici e CageFS, care dă fiecărui cont propriul spațiu izolat.
• Protecție anti-malware activă, nu o scanare pe care o pornești manual. Imunify360 e standardul de facto pe hosting cu cPanel.
• Limitare la brute force pe zonele de login. Fără ea, un site WordPress public primește mii de încercări pe zi.
• Security headers setate corect, pentru că altfel le punem noi în .htaccess pe fiecare proiect.

4. Backup: frecvență, retenție și, mai important, restaurare

Întrebarea de test nu e „faceți backup?”. Toată lumea face backup. Întrebarea e: cât durează o restaurare completă și cine o execută?

Un backup zilnic, păstrat câteva zile, acoperă majoritatea situațiilor. Nu acoperă un magazin care primește comenzi continuu, pentru că între două backup-uri poți pierde o zi de comenzi. Acolo punem un strat propriu peste, cu export mai des al bazei de date.

Și mai e o confuzie pe care o clarificăm des cu clienții. RAID 10 nu e backup. E o configurație de discuri care te protejează dacă se strică un disc. Dacă ștergi din greșeală o tabelă, RAID-ul o va oglindi ștearsă, foarte fidel și foarte rapid.

5. Suportul tehnic: cine răspunde, în ce limbă, în cât timp

Criteriul ăsta se vede abia când ai o problemă, motiv pentru care aproape nimeni nu îl verifică înainte să cumpere.

Verificăm trei lucruri separat: ce canale există, ce program real are fiecare canal, și în cât timp vine primul răspuns care chiar înseamnă ceva.

Distincția dintre canale e esențială și puțini o citesc corect. „Suport 24/7″ înseamnă de obicei ticket, nu telefon. O linie telefonică cu program de birou e perfect rezonabilă, dar trebuie să știi asta înainte, nu sâmbătă seara.

În 2025 am deschis 34 de tichete pentru site-urile clienților noștri. Mediana primului răspuns a fost sub 30 de minute. Cel mai lung timp de așteptare a fost puțin peste patru ore, într-o noapte de duminică, pentru ceva care nu era urgent.

6. Migrarea: cât de greu e să intri și cât de greu e să ieși

Un furnizor bun te ajută să intri. Un furnizor corect te lasă și să pleci. Verificăm dacă există asistență la migrare și, la fel de important, dacă ai acces la propriile date fără să ceri voie: export complet al bazei de date, acces la fișiere, control asupra zonei DNS.

Practic, o migrare bine făcută arată așa. Cu 24 până la 48 de ore înainte cobori TTL-ul înregistrărilor DNS la câteva minute. Copiezi fișierele și baza de date pe noul server, testezi pe un host temporar, apoi faci un sync final al diferențelor și schimbi înregistrările. Fereastra în care site-ul chiar e indisponibil e cea dintre ultimul sync și propagare.

Cea mai complexă migrare pe care am făcut-o anul trecut a fost un magazin WooCommerce cu aproximativ 12.000 de produse și istoric de comenzi de cinci ani. Am lucrat trei ore, noaptea. Downtime-ul real, în care clientul nu putea primi comenzi, a fost sub zece minute.

7. Compatibilitatea cu WordPress și cu stack-ul nostru

Aproape 80% din ce livrăm e WordPress, deci lista e concretă:

• versiuni PHP multiple, selectabile pe fiecare site, ca să putem ține un proiect vechi pe o versiune și unul nou pe alta;
• LiteSpeed sau echivalent, cu cache care se integrează la nivel de server, nu doar la nivel de PHP;
• Redis sau alt object cache, obligatoriu pentru WooCommerce;
• acces la cron real, nu doar la cron-ul WordPress declanșat de vizitatori;
• acces la baza de date și la fișiere fără să deschidem ticket.

Panoul contează și el. cPanel nu e modern, dar e cunoscut de toată lumea, iar asta înseamnă că un client care pleacă de la noi nu rămâne blocat într-o interfață pe care nimeni n-o mai știe.

Pe partea de cache, documentația LiteSpeed explică bine diferența dintre cache la nivel de server și pluginurile care fac același lucru din PHP. Pe scurt: primul răspunde înainte ca WordPress să pornească, al doilea după.

8. Magazine online: unde se rupe un shared hosting

Un magazin nu se comportă ca un site de prezentare. Paginile de produs se pot servi din cache, dar coșul, checkout-ul și contul de client nu, pentru că fiecare vizitator vede altceva. Traficul greu cade exact pe partea care nu poate fi accelerată cu cache.

Verificăm deci limitele reale de resurse, nu doar spațiul: câte procese simultane poate rula contul și ce se întâmplă când le depășește. Pe hosting cu CloudLinux, depășirea se traduce în eroarea 508 Resource Limit Reached, care e de fapt un serviciu făcut ție: serverul îți taie ție procesele în loc să pice pentru toată lumea. Detaliile despre cum funcționează limitele sunt în documentația CloudLinux.

Experiența noastră, pe cifre: un magazin pe WooCommerce cu până la aproximativ 5.000 de sesiuni pe zi și un catalog rezonabil funcționează bine pe un pachet de shared hosting bun. Peste pragul ăsta, sau dacă checkout-ul are integrări multiple, discutăm de VPS înainte de campanie, nu în timpul ei.

9. Scalabilitatea: ce se întâmplă când proiectul crește

Ultima întrebare din grilă e cea mai ieftină de pus și cea mai scumpă de ignorat: ce fac când proiectul depășește pachetul ăsta?

Un furnizor cu o singură categorie de produs te obligă la o migrare completă exact în momentul în care ai cel mai puțin timp. Unul care are shared, VPS și opțiuni peste îți permite un upgrade planificat, în aceeași infrastructură, fără schimbare de DNS și fără weekend pierdut.

Hosting ieftin vs hosting potrivit proiectului

Nu suntem împotriva pachetelor ieftine și n-o să-ți spunem că trebuie să plătești mult. O să-ți spunem unde e linia.

Un pachet de bază e alegerea corectă pentru un site de prezentare cu trafic mic, pentru un portofoliu, pentru un blog la început. Site-ul are câteva pagini, conținutul se schimbă rar, nimeni nu pierde bani dacă e jos o oră. Să plătești triplu acolo e risipă și ți-o spunem ca atare.

Linia se trece în momentul în care site-ul produce bani sau lead-uri. Un formular de contact care aduce cereri de ofertă e deja infrastructură de vânzări. Din clipa aia, diferența dintre două pachete e mai mică decât un singur client pierdut.

Ce plătești când plătești foarte puțin e, de obicei, densitatea: mai multe conturi pe același server, limite mai strânse, suport mai lent. Nu e neapărat o înșelătorie, e un model de business. Trebuie doar să știi în care model ești.

Ce furnizor folosim noi și cum am ajuns aici

De la ce am plecat

Până în 2020 aveam clienți la 11 furnizori diferiți. Mulți moșteniți de la cine construise site-ul înainte, fiecare cu alt panou, alte limite, alt flux de suport.

Problema nu era neapărat că unii erau mai puțin pregătiți. Problema era că nu aveam o procedură. La fiecare incident, primele 20 de minute se duceau pe „unde e site-ul ăsta și cum intru”. Într-o zi cu două incidente simultane, cele 20 de minute devin ora în care clientul te sună a doua oară.

De-a lungul timpului, am testat și lucrat cu peste 11 furnizori de hosting, iar experiențele au fost foarte diferite. Din păcate, în multe situații ne-am lovit de probleme care ne-au făcut să înțelegem cât de important este să alegi cu atenție furnizorul de hosting: răspunsuri întârziate din partea echipei de suport, servere supraîncărcate și resurse insuficiente, probleme recurente de performanță sau, pur și simplu, lipsa unei echipe tehnice suficient de bine pregătite pentru a interveni atunci când apar situații neprevăzute.

Pentru noi, hostingul nu este un detaliu secundar. Gestionăm proiecte importante pentru clienții noștri, iar stabilitatea, viteza și disponibilitatea site-urilor pe care le administrăm sunt esențiale. Nu ne permitem ca un site să fie lent sau indisponibil din cauza unor probleme care țin de infrastructura de hosting și nici să așteptăm ore întregi pentru un răspuns atunci când apare o situație urgentă.

Tocmai de aceea, după toate aceste experiențe, am continuat să căutăm un furnizor care să fie în concordanță cu standardele și exigențele noastre.

De ce am ales HostRiver și ce am verificat înainte

Primul site l-am mutat la HostRiver în 2020, pentru un client care avea probleme de viteză. A funcționat, apoi am mutat încă vreo câteva, iar în 2021 am luat decizia de a standardiza.

HostRiver este un furnizor românesc de servicii de găzduire web, cu datacenter în Cluj-Napoca, care oferă soluții de hosting shared, găzduire WordPress, AI application hosting, soluții pentru site-uri dezvoltate prin vibe coding cu integrare MCP, servere VPS și înregistrare de domenii web.

Ce am verificat înainte să mutăm portofoliul, în ordinea din grila de mai sus:

• Performanță. Stocare NVMe pe toată flota, LiteSpeed Enterprise, cache configurabil. TTFB-urile măsurate după mutare s-au încadrat în intervalele din criteriul 1.
• Infrastructură. Datacenterul e în Liberty Technology Park, construit la standardele Tier 3 și TIA 942, cu certificare ISO 27001. Am fost acolo. Pentru cine nu poate ajunge, pagina de datacenter are specificațiile și un tur virtual.
• Securitate. CloudLinux pentru izolarea resurselor, CageFS, Imunify360, security headers automate. Adică fix lista din criteriul 3, fără să o construim noi.
• Suport. Ticket 24/7 inclus în orice pachet. Linia telefonică funcționează luni până vineri, între 09:00 și 18:00. Am verificat asta înainte, nu după.
• Date în România. Pentru clienții din zona medicală și pentru cei cu departament juridic activ, faptul că serverul e în țară scurtează o discuție care altfel durează săptămâni.

Ce ținem acolo azi

Peste 180 de site-uri active de clienți. Aproximativ 80 sunt site-uri de prezentare și site-uri de firmă pe WordPress, în jur de 60 sunt magazine pe WooCommerce, iar restul rulează pe VPS-uri tot la HostRiver, fie pentru că au depășit shared-ul, fie pentru că au nevoie de o configurație proprie. Pentru proiecte noi de prezentare mergem implicit pe pachetele lor pentru WordPress.

O problemă reală și cât de mult contează suportul tehnic

Anul trecut, magazinul unui client a început să dea 508 în plin sezon. Am deschis ticket la 22:30 și am primit logurile de consum de resurse în mai puțin de 10 minute.

Din ele a reieșit că vinovatul era un plugin de recenzii care scria în baza de date la fiecare încărcare de pagină, inclusiv pentru boți. Deci problema nu era la hosting. Era la noi, mai exact la un plugin pe care îl aprobasem fără să-i testăm comportamentul sub trafic.

Îl scriem aici pentru că e important: un suport bun nu îți rezolvă mereu problema, dar îți dă datele cu care ți-o rezolvi singur. Diferența dintre 10 de minute și trei ore până la loguri era, în seara aia, tot.

Unde nu recomandăm soluția asta

Nu recomandăm hosting administrat pentru proiecte foarte mari, cu echipă internă de DevOps. Când clientul are oameni care gândesc infrastructura ca produs, cerințele se schimbă complet: infrastructură definită în cod cu Terraform, autoscaling pe grupuri de instanțe, containere orchestrate, cozi de mesaje gestionate, replicare multi-regiune, medii de staging identice create și distruse la fiecare deploy.

Pentru astfel de proiecte am lucrat pe AWS. Nu pentru că e mai rapid, ci pentru că e altă categorie de unealtă. Un hosting administrat îți dă o platformă stabilă pe care nu trebuie s-o întreții. AWS îți dă piese din care construiești exact ce vrei, cu condiția să ai cine să le întrețină. Fără o echipă internă, a doua variantă e mai scumpă și mai fragilă, nu mai bună. Cadrul de referință pe care îl folosim în discuțiile astea e AWS Well-Architected.

Regula noastră, simplu spusă: dacă clientul nu are pe cineva care să răspundă la 3 dimineața pentru infrastructură, nu are ce căuta pe infrastructură care poate ceda la 3 dimineața.

Alte trei limite, pe care le spunem clienților din start:

1. Nu există un flux de staging cu un click la nivel de platformă. Ne facem staging pe subdomeniu, ceea ce funcționează, dar e un pas manual în plus.
2. Backup-ul zilnic inclus nu e suficient pentru un magazin cu volum mare de comenzi. Punem un strat propriu peste, cu export mai des al bazei de date.
3. Suportul telefonic are program de birou. Pentru urgențe de weekend rămâne ticketul, care răspunde, dar dacă vrei o voce la telefon duminică, e bine să știi asta dinainte.

Cum decizi și tu: zece întrebări pentru orice furnizor

Lista e reutilizabilă. Copiaz-o și trimite-o ca atare oricărui furnizor pe care îl evaluezi.

1. Ce tip de stocare folosiți și e aceeași pe toate pachetele?
2. Ce server web rulează și ce soluție de cache e inclusă?
3. Ce limite de resurse are contul meu, exprimate în cifre, și ce se întâmplă când le depășesc?
4. Cât de des se face backup, cât timp se păstrează și cât durează o restaurare completă?
5. Restaurarea o fac eu din panou sau o faceți voi la cerere?
6. Suportul e disponibil 24/7 pe ce canal, exact? Care e programul liniei telefonice?
7. Unde sunt fizic serverele și ce certificări are datacenterul?
8. Ajutați la migrare? Și dacă vreau să plec, îmi pot lua singur un export complet?
9. Ce opțiuni am când depășesc pachetul ăsta și presupune upgrade-ul o migrare?
10. Pot ține domeniul la alt registrar dacă vreau?

Un furnizor bun răspunde la toate în scris și fără ocolișuri. Ezitarea la întrebările 3, 4, 6 și 8 e cel mai util semnal pe care îl poți obține gratuit.

Întrebări frecvente

Cum aleg hostingul potrivit pentru un site WordPress? 

Verifică patru lucruri: versiuni PHP recente și selectabile, un server web cu cache la nivel de server (LiteSpeed sau echivalent), stocare NVMe și backup zilnic cu restaurare rapidă. Pentru majoritatea site-urilor de prezentare, un pachet de shared hosting bun e suficient. Nu ai nevoie de VPS pentru un site cu zece pagini.

Ce trebuie să verific la un furnizor de hosting înainte să cumpăr? 

Cele nouă criterii din articol, comprimate: performanță măsurată ca TTFB, redundanță pe alimentare și DNS, securitate la nivel de server, backup cu restaurare testată, program real al suportului pe fiecare canal, asistență la migrare, compatibilitate cu stack-ul tău, limite de resurse potrivite pentru e-commerce și o cale clară de upgrade.

Contează suportul tehnic atunci când aleg hostingul? 

E criteriul care se vede abia când ai o problemă, deci da. Verifică programul real pe fiecare canal, nu sloganul de pe homepage. „Suport 24/7″ înseamnă aproape mereu ticket, iar linia telefonică are de obicei program de birou. Ambele sunt în regulă, dacă le știi dinainte.

Când am nevoie de VPS în loc de shared hosting? 

Când atingi constant limitele de resurse ale contului, nu când ai o zi cu trafic mare. Alte motive valide: ai nevoie de o configurație pe care shared-ul nu o permite, rulezi mai multe aplicații pe același proiect, sau ai cerințe de izolare venite din partea clientului tău.

Ce hosting e potrivit pentru un magazin online? 

Unul care ține la ore de vârf, pentru că partea grea a unui magazin, adică coșul și checkout-ul, nu poate fi servită din cache. Cere limitele de resurse în cifre, object cache de tip Redis, backup mai des decât zilnic dacă ai volum, și o cale de upgrade pe care să o poți folosi înainte de campanie.

Cât durează migrarea unui site pe alt hosting și ce risc am? 

Partea sensibilă nu e copierea fișierelor, ci sincronizarea finală a bazei de date și propagarea DNS. Cu TTL-ul coborât din timp, downtime-ul real poate fi de câteva minute. Cea mai complexă migrare făcută de noi anul trecut, un magazin cu 12.000 de produse, a însemnat trei ore de lucru și sub zece minute de indisponibilitate efectivă.

Contează unde e localizat serverul? 

Contează pentru latența față de vizitatorii din România și pentru claritatea juridică privind locul unde sunt stocate datele. Site-urile clienților noștri sunt găzduite la HostRiver, în datacenterul din Cluj-Napoca, tocmai pentru că un server în țară scurtează discuțiile de conformitate. Pentru un public internațional, discuția se mută spre CDN, nu spre locația serverului.

Ce furnizor de hosting recomandați voi? 

Pentru site-uri de prezentare, site-uri de firmă, proiecte WordPress și magazine mici și medii pe WooCommerce recomandăm HostRiver, unde găzduim peste 180 de site-uri de clienți din 2020. Pentru proiecte foarte mari, cu echipă internă de DevOps și infrastructură definită în cod, recomandăm AWS. Nu sunt soluții concurente, sunt categorii diferite de unealtă.

Merită să plătesc mai mult pentru hosting dacă am un site mic? 

Nu întotdeauna. Un site de prezentare cu trafic mic funcționează bine pe un pachet de bază, iar să plătești triplu acolo e risipă. Linia se trece în momentul în care site-ul produce bani sau lead-uri. Atunci diferența dintre două pachete e mai mică decât un singur client pierdut.

Concluzie

Alegerea hostingului nu e o decizie de preț, e o decizie de procedură. Întrebarea corectă nu e „cât costă”, ci „ce fac când nu merge, și cine răspunde”.

După 14 ani și peste 400 de proiecte, răspunsul nostru e să ținem majoritatea site-urilor clienților noștri la un singur furnizor pe care îl cunoaștem bine, unde știm că avem mereu o echipă profesionistă pe care ne putem baza și să ieșim din tipar doar când proiectul chiar cere altceva. Pentru clienții cu echipă internă de DevOps și nevoi de infrastructură complexă, mergem pe AWS și o spunem din prima discuție.

Dacă vrei un site construit și administrat cap-coadă, inclusiv partea de hosting, hai să vorbim. Iar dacă preferi să te uiți singur la ce include un pachet, ai lista completă pe site-ul HostRiver.

Transparență. Suntem client HostRiver din 2020 și găzduim acolo majoritatea site-urilor pe care le administrăm pentru clienți. Articolul nu e plătit, nu a fost revizuit de furnizor înainte de publicare și nu conține linkuri de afiliere. Criteriile din el le aplicăm oricărui furnizor, inclusiv celui pe care îl folosim.