Shared hosting vs VPS: de ce ai nevoie cu adevărat în 2026?

Shared hostingul este potrivit pentru site-uri statice mici, portofolii personale și bloguri cu trafic redus. Un VPS devine alegerea mai bună când rulezi WooCommerce, ai trafic mare, implementezi software custom, ai nevoie de medii de staging realiste sau vrei să repari performanța în loc să lucrezi în jurul limitelor platformei. Detaliul pe care multe ghiduri îl evită este acesta: un VPS unmanaged ieftin, lăsat pe setări implicite, poate fi mai lent decât un shared hosting bun dacă nu știi să tunezi PHP-FPM, să administrezi firewallul sau să monitorizezi memoria. Întrebarea corectă nu este care tehnologie este superioară. Întrebarea corectă este care se potrivește traficului, nivelului tău tehnic, bugetului și disponibilității tale de a administra infrastructură.

Ce este shared hostingul, de fapt?

Shared hostingul pune mai multe conturi de clienți pe același server fizic. Fiecare cont primește un director separat, acces la un panou de control și servicii comune: server web, server de email, server de baze de date și o parte din resursele sistemului. Fiecare cont concurează pentru aceleași nuclee CPU, aceeași memorie RAM, același I/O pe disc și aceeași capacitate de rețea.

Pe platformele shared moderne, mecanismul real de izolare este de obicei CloudLinux cu limite LVE, adică Lightweight Virtual Environment. Acestea sunt limite dure, impuse la nivel de kernel. Valorile tipice arată așa:

Parametru LVE	Valoare tipică	Ce înseamnă
SPEED	100% sau 1 core CPU	Timpul maxim de CPU pe care îl poate consuma contul
PMEM	1 GB	Limita de memorie fizică per cont
IO	1.024 KB/s	Plafonul pentru citire și scriere pe disc
EP	20	Numărul maxim de cereri PHP, sesiuni SSH sau cron joburi concurente
NPROC	100	Numărul maxim de procese pe care contul le poate porni

Când atingi aceste limite, serverul returnează eroarea HTTP 508, Resource Limit Is Reached. Dacă limita este de memorie, PHP moare cu mesajul Fatal error: Allowed memory size exhausted. Dacă serverul de baze de date este suprasolicitat de alte conturi, poți primi erori 502 sau 504 Gateway Timeout chiar dacă propriul cont nu a atins limitele LVE. Performanța ta depinde de vecini pe care nu îi poți vedea.

Majoritatea planurilor shared impun și limite de inode între 100.000 și 500.000 de fișiere. Fiecare fișier contează: WordPress core, imaginile încărcate, fiecare dintre cele șase dimensiuni de thumbnail generate de WordPress, fișierele pluginurilor, fișierele de cache. Un site cu 50.000 de imagini originale poate ajunge la peste 300.000 de inode-uri. Când atingi limita, uploadurile eșuează, pluginurile de cache se rup și actualizările se blochează.

Mai împarți și un IP public cu sute de alte conturi. Dacă un client trimite spam, întregul IP poate ajunge pe blacklisturi. Înregistrările reverse DNS, adică PTR, sunt controlate de furnizor, nu de tine.

Shared hostingul este o unealtă cu constrângeri clare. Dacă înțelegi constrângerile, poți decide corect dacă se potrivește site-ului tău.

Ce este un VPS, de fapt?

Un Virtual Private Server, sau VPS, împarte un server fizic în mașini virtuale izolate. Spre deosebire de shared hosting, unde primești un cont de utilizator, un VPS îți oferă o instanță completă de sistem de operare cu acces root. Poți modifica parametri de kernel, instala software, rula servicii în fundal, configura firewallul și reporni serverul fără să afectezi alți clienți.

Tehnologia de virtualizare contează. Cele două abordări comune sunt:

KVM, adică Kernel-based Virtual Machine, oferă virtualizare hardware completă. Fiecare VPS rulează propriul kernel, independent de host. Izolarea este puternică: un kernel panic într-un VPS nu le afectează pe celelalte. KVM este standardul pentru hosting VPS de producție.

LXC și OpenVZ folosesc containerizare. Toate containerele partajează kernelul hostului. Modelul este mai ușor și permite densitate mai mare, dar izolarea este mai slabă. O vulnerabilitate de kernel pe host afectează toate containerele. Nu poți încărca module de kernel și nu poți rula un kernel diferit. KVM este alegerea mai sigură dacă ai nevoie de izolare garantată.

Un VPS îți oferă resurse dedicate: nuclee CPU, RAM și I/O pe disc garantate. Nu concurezi în același fel cu vecini zgomotoși. Performanța este mai predictibilă. Primești și cel puțin un IP dedicat, pe care îl controlezi. Poți seta reverse DNS, poți rula propriul server de mail și poți construi reputație de trimitere independent de alți clienți.

Diferența critică este între managed și unmanaged.

Un VPS unmanaged este un server gol cu date de acces root. Tu instalezi serverul web, baza de date, PHP, panoul de control, firewallul, backupurile și monitorizarea. Tu aplici patchuri de securitate și configurezi SSL. Furnizorul menține hardware-ul fizic și rețeaua. Atât.

Un VPS managed include administrare de server din partea furnizorului. Echipa instalează stackul, aplică patchuri, configurează firewallul, setează backupuri, monitorizează uptime-ul și depanează probleme. Acesta este modelul ServerSpan: sysadmini certificați gestionează stratul de server, iar tu gestionezi ce rulează deasupra.

Adevărul onest este simplu: un VPS îți oferă control, dar controlul cere competență sau buget. Dacă nu ai niciuna dintre ele, un VPS devine o vulnerabilitate, nu un upgrade.

Diferențele reale

Tabelul de mai jos compară shared hostingul și VPS-ul pe dimensiunile care contează în operarea zilnică. Valorile sunt intervale tipice din industrie, nu detalii specifice planurilor ServerSpan.

Factor	Shared hosting	VPS managed sau unmanaged
Cost lunar tipic	3-15 USD	8-80+ USD
Acces root	Nu	Da
Alocare CPU	Partajată, limitată la aproximativ 1 core	1-8+ vCPU dedicate
RAM	512 MB-1 GB ca limită LVE	1 GB-32 GB+ dedicat
Cereri PHP concurente	10-30 prin CloudLinux LVE	Configurabil, limitat de RAM și CPU
Limite inode	100.000-500.000	Fără limită practică în afara discului
Limite trimitere email	100-500/oră tipic	Configurabil
Instalare software custom	Nu, listă restricționată	Libertate completă
Mediu de staging	Limitat, împarte același LVE	Poate oglindi producția
Control certificat SSL	AutoSSL prin furnizor	Control complet
Redis sau Memcached	Rar disponibil	Standard pe managed sau instalabil pe unmanaged
Competență tehnică necesară	Redusă	Medie spre ridicată
Administrare server	Furnizorul gestionează tot	Tu gestionezi OS-ul sau furnizorul îl gestionează pe managed
IP dedicat	IP partajat cu sute de conturi	Unul sau mai multe incluse
Control kernel	Nu	Complet pe KVM sau absent pe LXC

Rândurile care contează cel mai mult în practică sunt EP, adică entry processes, cererile PHP concurente și disponibilitatea Redis.

Entry processes sunt criminalul tăcut pe shared hosting. O limită de 20 pare generoasă până realizezi că fiecare cerere PHP necache-uită, fiecare sesiune WordPress admin, fiecare cron job și fiecare apel AJAX consumă un slot. Cart fragments din WooCommerce, care rulează la fiecare încărcare de pagină pentru fiecare vizitator, pot epuiza un pool de 20 în câteva secunde pe un magazin moderat de ocupat. Pe un VPS, calculezi pm.max_children în funcție de RAM-ul real și scalezi după nevoie.

Disponibilitatea Redis și Memcached este al doilea diferențiator. Object caching elimină interogările repetate către baza de date pentru cereri identice. Pe shared hosting, object caching persistent este de obicei indisponibil pentru că socketul Redis sau Memcached nu este expus conturilor individuale. Pe un VPS, îl instalezi și îl configurezi. Pentru un site WooCommerce cu mii de produse, diferența dintre o interogare de 200 ms în baza de date și un răspuns Redis de 2 ms este diferența dintre o pagină care convertește și una de pe care vizitatorul pleacă.

Limitele de inode sunt al treilea motiv practic de îngrijorare. Site-urile cu multe imagini, pluginuri sau cataloage mari de produse lovesc plafoanele de inode pe shared hosting. Pe un VPS, limita reală este spațiul pe disc.

Shared hosting: unde funcționează cu adevărat

Shared hostingul este alegerea corectă mai des decât vor să recunoască unele companii de hosting. Ia în calcul shared hostingul dacă situația ta se potrivește cu una dintre următoarele:

Site-uri de prezentare pentru firme mici. Un site cu cinci pagini, Home, Despre, Servicii, Contact și un blog actualizat lunar nu are nevoie de VPS. Are nevoie de hosting fiabil, backupuri automate și un panou de control pe care proprietarul îl poate folosi.

Portofolii personale și bloguri sub 10.000 de vizite pe lună. La acest nivel de trafic, un site WordPress bine cache-uit pe shared hosting rămâne ușor în limitele LVE. Un pool EP de 20 gestionează fără efort volumul concurent de cereri.

Landing pages și microsite-uri de campanie. Paginile cu scop unic, interactivitate limitată și fără e-commerce nu justifică overheadul administrării unui VPS.

Site-uri unde proprietarul nu are timp pentru administrare de server și nici interes să învețe. Dacă SSH, chmod și systemctl restart php-fpm nu fac parte din vocabularul tău, hostingul VPS unmanaged nu este pentru tine. VPS-ul managed este o opțiune, dar costă mai mult. Dacă bugetul nu ajunge acolo, rămâi pe shared hosting.

Proiecte cu buget realmente limitat. Un plan shared de 5 USD pune un site online. Un VPS unmanaged de 5 USD îți dă un server gol care cere ore de configurare înainte să servească o pagină. Pentru unele proiecte, costul acesta de timp este inacceptabil.

Shared hostingul eșuează când împingi site-ul în limitele lui. Dacă site-ul tău nu împinge acele limite, shared hostingul funcționează bine. Nu lăsa pe nimeni să îți vândă un VPS pentru un site care nu are nevoie de el.

Shared hosting: unde se rupe cu adevărat

Secțiunea aceasta acoperă modurile de eșec care apar în tichete la 2 dimineața. Dacă le înțelegi, recunoști mai repede dacă site-ul tău a depășit shared hostingul.

Problema WordPress Heartbeat

WordPress rulează Heartbeat API prin admin-ajax.php la fiecare 15 până la 60 de secunde pentru fiecare utilizator autentificat. Fiecare cerere heartbeat consumă aproximativ 0,2 până la 0,3 secunde de CPU și un slot de entry process. Un singur editor cu cinci taburi deschise poate genera 5 până la 20 de cereri concurente. Doi editori cu mai multe taburi pot consuma tot poolul EP. Alți vizitatori văd erori 508 în timp ce editorul doar lucrează la conținut. Pe un VPS, controlezi frecvența Heartbeat. Pe shared hosting, ești blocat în valorile implicite ale platformei.

WooCommerce cart fragments

Endpointul WooCommerce /?wc-ajax=get_refreshed_fragments rulează la fiecare încărcare de pagină pentru fiecare vizitator. Cererea nu este cache-uibilă implicit pentru că returnează date specifice coșului. Cu 100 de vizitatori concurenți, ai 100 de procese PHP ocupate cu cart fragments. Pe shared hosting cu EP=20, 80 dintre vizitatori primesc eroare 508 sau timeout. Magazinul devine inaccesibil în timpul vârfurilor de trafic.

Workaroundul standard pe shared hosting este să dezactivezi cart fragments pe paginile care nu sunt coș sau checkout, printr-un plugin. Ajută, dar este tot un workaround pentru o limitare de platformă. Pe un VPS, gestionezi sarcina prin tuning PHP-FPM, object caching și suficienți workeri.

Limitele de conexiuni la baza de date

Conturile de shared hosting sunt de obicei limitate la 10 până la 30 de conexiuni concurente la baza de date. O pagină WordPress standard folosește o conexiune. Checkoutul WooCommerce folosește mai multe conexiuni: creare comandă, reducere stoc, căutare client, callback de la gatewayul de plată. Într-o campanie sau flash sale, conexiunile se epuizează rapid. Rezultatul este Error establishing a database connection pe storefront, în timp ce dashboardul admin încă se încarcă.

Pe un VPS, setezi max_connections în my.cnf sau mariadb.cnf în funcție de nevoile tale. Un magazin WooCommerce mic poate rula confortabil cu 100 până la 150 de conexiuni. Ai controlul acesta.

Livrabilitatea emailului pe IP-uri partajate

Când trimiți email din shared hosting, mesajele pleacă de pe un IP împărțit cu sute de conturi. Dacă un cont este compromis, întregul IP poate ajunge pe liste negre la Spamhaus, Barracuda sau Microsoft SNDS. Confirmările de comandă pot începe să fie respinse sau să ajungă în spam.

Nu poți cere delistarea unui IP partajat pe care nu îl controlezi. Nu poți seta reverse DNS să se potrivească domeniului de trimitere. Aceste controale cer IP dedicat, pe care shared hostingul nu îl oferă.

Staging care împarte limitele cu producția

Mulți furnizori shared oferă staging cu un click. Ce nu spun clar este că mediul de staging rulează în același container LVE ca producția. Împarte același pool EP, aceeași limită de memorie și aceeași cotă de inode. Dacă faci load test pe staging, consumi resursele producției. Un staging care împarte limitele producției este o copie de fișiere cu alt URL, nu un mediu real de staging.

Epuizarea inode-urilor în practică

Site-ul WordPress al unui fotograf cu 50.000 de imagini originale și șase dimensiuni de thumbnail înregistrate generează peste 300.000 de fișiere imagine. Adaugă fișierele core, pluginurile, temele, cache-ul și backupurile, iar totalul se apropie de 400.000 până la 500.000 de inode-uri. Multe planuri shared au limită la 250.000. Site-ul nu mai poate genera thumbnails, crea fișiere de cache sau finaliza actualizări. Biblioteca media începe să afișeze imagini stricate.

Pe un VPS, remedierea este simplă: nu există o limită separată de inode în afara capacității discului. Pe shared hosting, ștergi fișiere, muți media în storage extern sau faci upgrade. Niciuna dintre aceste soluții nu repară problema de bază.

Logul care spune de obicei adevărul

Când un site pe shared hosting se strică, mesajele de eroare urmează tipare previzibile. Verifică aceste locuri:

cPanel Error Logs: mergi la cPanel, Metrics, Errors. Caută:

• 508 Resource Limit Is Reached: ai atins limita CloudLinux LVE.
• Fatal error: Allowed memory size of 268435456 bytes exhausted: limita de memorie PHP a fost depășită.
• 502 Bad Gateway sau 504 Gateway Time-out: handlerul PHP upstream sau serverul de baze de date nu a răspuns la timp.

WordPress debug.log: dacă WP_DEBUG_LOG este activat în wp-config.php, verifică /wp-content/debug.log pentru conflicte de pluginuri, eșecuri de interogări în baza de date și erori fatale PHP.

Server error_log: în directorul home al contului sau în public_html, fișierul error_log înregistrează erori fatale PHP, epuizare de memorie și timeouturi de execuție. Dacă fișierul crește cu megabytes pe zi, site-ul este în suferință.

Dacă vezi erori 508 mai des de o dată pe lună, site-ul tău a depășit shared hostingul. Niciun plugin de cache și nicio optimizare de imagini nu repară o limită LVE dură.

VPS: ce se schimbă când faci upgrade

Mutarea de pe shared hosting pe VPS schimbă mai mult decât prețul lunar. Iată ce se îmbunătățește și ce devine posibil.

Pooluri PHP-FPM configurabile

Pe shared hosting, PHP-FPM rulează ca serviciu de sistem cu setări globale. Nu controlezi procesele worker. Pe un VPS, configurezi pooluri PHP-FPM per site.

Setarea critică este pm.max_children. Dacă o setezi prea jos, cererile se pun la coadă în vârfurile de trafic. Dacă o setezi prea sus, epuizezi RAM-ul și declanșezi OOM killer.

Calculul este:

pm.max_children = (RAM disponibil - rezervă OS și bază de date) / memoria medie per proces PHP

Exemplu, pe un VPS de 4 GB cu 1 GB rezervat pentru OS, MySQL și Redis:

• disponibil pentru PHP: aproximativ 3 GB sau 3.072 MB
• memorie medie proces PHP-FPM pentru WordPress cu WooCommerce: aproximativ 50-80 MB
• pm.max_children = 3.072 / 65, adică aproximativ 47

Apoi setezi pm.start_servers, pm.min_spare_servers și pm.max_spare_servers proporțional. Pe shared hosting, calculul acesta este imposibil pentru că nu controlezi poolul și nu vezi metrici la nivel de proces.

Tuning OPcache

PHP OPcache păstrează bytecode compilat în memorie, eliminând pasul de parsare și compilare la fiecare cerere. Pe shared hosting, OPcache are adesea valori implicite de 128 MB memorie și 4.000 de fișiere accelerate. Pe un VPS, îl tunezi în php.ini:

opcache.memory_consumption=256
opcache.max_accelerated_files=10000
opcache.revalidate_freq=2
opcache.validate_timestamps=1

Pentru un site WooCommerce ocupat, 256 MB până la 512 MB de OPcache elimină recompilarea repetată a fișierelor din pluginuri și temă. Doar această schimbare poate tăia 100 până la 300 ms din timpul de încărcare al paginilor necache-uite.

Redis și Memcached pentru object caching

Un VPS îți permite să rulezi Redis sau Memcached ca serviciu local. Pluginurile de object caching pentru WordPress păstrează rezultatele interogărilor în baza de date, transients și date de sesiune în memorie. Cererile următoare evită complet baza de date. Redis poate susține și stocarea sesiunilor WooCommerce, reducând scrierile în baza de date în perioadele de trafic ridicat. Pe shared hosting, object caching persistent este de obicei indisponibil. Fiecare încărcare de pagină interoghează baza de date pentru date care se schimbă rar.

IP dedicat și reputație email

Un IP dedicat îți oferă control asupra reputației de trimitere. Poți cere înregistrări reverse DNS, adică PTR, care se potrivesc domeniului de trimitere, o cerință importantă pentru livrabilitate la Gmail, Outlook și Yahoo. Poți monitoriza blacklisturile pentru IP-ul tău, nu pentru un IP împărțit cu sute de necunoscuți.

Un IP dedicat nou are nevoie de o perioadă de warm-up de 2 până la 6 săptămâni. Trebuie să crești gradual volumul de trimitere pentru a construi reputație. Trimiterea bruscă a 10.000 de emailuri de pe un IP rece declanșează filtre anti-spam.

Snapshoturi complete de sistem

Backupurile de shared hosting acoperă fișiere și baze de date. Nu surprind configurația serverului: setări PHP, cron joburi, certificate SSL, reguli de firewall sau pachete instalate.

Un snapshot VPS surprinde întreaga stare a discului. Dacă o schimbare de configurație strică serverul, restaurezi snapshotul. Asta face experimentarea mai sigură. Pe shared hosting, nu poți face snapshot la platformă pentru că nu o controlezi.

Reguli custom de caching Nginx

Pe un VPS care rulează Nginx, poți configura fastcgi_cache pentru a cache-ui răspunsurile PHP dinamice la nivel de server web. Spre deosebire de cachingul pe bază de plugin, care tot invocă PHP, microcachingul Nginx servește răspunsuri direct din memorie sau de pe disc fără să atingă PHP-FPM. Asta gestionează vârfuri de trafic care ar zdrobi un cont shared. Controlezi regulile de invalidare, cheile de cache și condițiile de bypass. De exemplu, poți cache-ui agresiv vizitatorii neautentificați și poți trimite cererile autentificate către PHP-FPM. Acest nivel de control este imposibil pe shared hosting.

Fără impact de la vecini

Pe un VPS, vârful de trafic sau atacul DDoS al altui client nu îți consumă direct resursele alocate. CPU-ul, RAM-ul și I/O-ul pe disc sunt rezervate pentru mediul tău. Predictibilitatea contează pentru site-urile de business, unde performanța variabilă înseamnă pierderi de venit.

Capcana VPS-ului ieftin

Aceasta este secțiunea pe care cele mai multe articole comparative o sar, deși ea costă cititorii cei mai mulți bani și cel mai mult timp. Un VPS unmanaged ieftin nu este automat mai bun decât shared hostingul. În multe cazuri, este mai rău.

Iată cum arată, de fapt, un VPS unmanaged de 5 până la 10 USD pe lună imediat după livrare.

Primești un server Linux gol cu 1 GB RAM și 1 vCPU. Fără server web, bază de date, PHP sau panou de control. Instalezi totul singur sau rulezi un script de stack cu un click care pune valori generice. Acele valori generice sunt de obicei greșite pentru WordPress.

Setările implicite PHP-FPM sunt insuficiente. Un php-fpm.conf tipic pe o instalare minimă setează pm.max_children la 5. Asta înseamnă mai puțini workeri PHP concurenți decât oferă un shared host bun. VPS-ul tău de 5 USD servește mai puțini vizitatori simultan decât un shared hosting de 8 USD până când tunezi manual poolul.

Fără panou de control, totul este manual. Crearea unui virtual host cere editarea nginx.conf. Adăugarea unui subdomeniu înseamnă un nou bloc vhost. Administrarea DNS înseamnă instalarea unui nameserver sau folosirea unui DNS extern cu zone configurate manual. Emiterea certificatelor SSL înseamnă instalarea Certbot și depanarea eșecurilor de validare.

Securitatea este complet responsabilitatea ta. Trebuie să configurezi firewallul, să instalezi fail2ban, să aplici actualizări de sistem, să monitorizezi malware și să întărești SSH: autentificare pe chei, port non-standard, root login dezactivat. Dacă ratezi oricare dintre aceste lucruri, serverul devine țintă. Boții automatizați scanează zilnic întregul spațiu IPv4 după credențiale implicite și software nepatchuit. Un VPS nou cu parolă root slabă este de obicei compromis în câteva ore.

Costurile ascunse se adună. cPanel pornește de la aproximativ 24,95 USD pe lună. DirectAdmin are licențe între 2 și 29 USD pe lună. Backupurile adaugă 2 până la 10 USD pe lună. Monitorizarea adaugă alt cost. Timpul tău are și el cost. Dacă facturezi 50 USD pe oră și petreci 3 ore pe lună pe sarcini de server, costul real al VPS-ului este cu 150 USD mai mare decât factura afișată.

Punctul de echilibru este acesta: un VPS unmanaged are sens când ai competențe Linux pentru configurare, securizare și tuning și când valorizezi controlul suficient încât să justifici timpul. Pentru ceilalți, VPS-ul managed sau shared hostingul de calitate este alegerea mai bună.

Managed VPS vs unmanaged: ce primești de fapt?

Termenul managed variază între furnizori. Tabelul de mai jos clarifică responsabilitățile în fiecare model.

Sarcină	VPS unmanaged	VPS managed, model ServerSpan
Instalare OS și setup inițial	Tu	Furnizorul
Patchuri de securitate și actualizări OS	Tu	Furnizorul
Configurare și administrare firewall	Tu	Furnizorul
Configurare și verificare backupuri	Tu	Furnizorul
Instalare și actualizare versiuni PHP	Tu	Furnizorul
Instalare și tuning MySQL sau MariaDB	Tu	Furnizorul
Administrare zone DNS	Tu	Furnizorul
Emiterea și reînnoirea certificatelor SSL	Tu	Furnizorul
Monitorizare server	Tu	Furnizorul
Scanare și eliminare malware	Tu	Furnizorul
Instalare și actualizare panou de control	Tu	Furnizorul
Suport infrastructură 24/7	Doar hardware și rețea	Suport full stack
Probleme la nivel de aplicație	Tu	Asistență orientativă
Management conținut și actualizări site	Tu	Tu
Cod custom și dezvoltare	Tu	Tu
Planificare creștere trafic și scalare	Tu	Furnizorul

Pe un VPS unmanaged, tu ești administratorul de sistem. Fiecare sarcină care menține serverul sigur, actualizat și performant cade în responsabilitatea ta. Dacă îți place munca aceasta și ai competențele necesare, hostingul unmanaged poate fi satisfăcător. Dacă nu, devine un al doilea job la care nu ai aplicat.

Pe hostingul VPS managed ServerSpan, sysadmini certificați gestionează stratul de infrastructură. Configurează stackul LAMP sau LEMP, tunează MySQL pentru workloadul tău, setează backupuri automate cu verificare, monitorizează consumul de resurse și răspund la alerte. Tu te concentrezi pe site sau aplicație. Când deschizi un tichet, răspunde un om cu experiență reală în administrare de servere. ServerSpan oferă și tagul de suport #noai pentru clienții care vor să sară peste răspunsurile automate și să discute direct cu un tehnician. Contează când magazinul este căzut și ai nevoie de un om competent, nu de un flowchart de chatbot.

Când să faci upgrade: semnale clare

Decizia de upgrade ar trebui să fie bazată pe simptome observabile, nu pe sfaturi abstracte despre scalare. Iată semnalele concrete că shared hostingul nu mai este suficient pentru site-ul tău.

Ai primit erori HTTP 508 de mai multe ori într-o lună. Un singur 508 într-un vârf de trafic poate fi o anomalie. Erorile 508 repetate înseamnă că site-ul depășește constant limitele LVE. Niciun plugin de cache nu repară o limită dură de resurse. Acesta este cel mai clar semnal de upgrade.

Time to First Byte, adică TTFB, este constant peste 1 secundă pentru pagini necache-uite. Măsoară cu WebPageTest sau Chrome DevTools. Un TTFB peste 1 secundă arată că serverul se chinuie să proceseze PHP și interogări de bază de date. Pe un VPS, poți tuneza și elimina problema.

Ai nevoie de Redis, Memcached, Elasticsearch sau extensii PHP custom. Dacă dezvoltatorul recomandă object caching prin Redis și shared hostul nu îl oferă, ai lovit o limită de platformă. Un VPS îți permite să instalezi extensiile PHP și serviciile necesare aplicației tale.

Rulezi WooCommerce cu peste 50 de vizitatori concurenți. WooCommerce generează cereri AJAX necache-uibile și interogări grele în baza de date. Pe shared hosting cu EP=20, 50 de vizitatori concurenți epuizează poolul de entry processes. Pentru magazine online, shared hostingul este viabil doar la trafic foarte mic. Când ai trafic constant cu intenție de cumpărare, VPS-ul devine necesar.

Ai nevoie de un mediu de staging care suportă sarcină realistă. Dacă nu poți face load test pe staging fără să afectezi producția, nu ai un mediu real de staging. Un VPS cu alocare de resurse identică producției îți oferă încredere că deploymenturile testate vor funcționa sub sarcină.

Ai probleme de livrabilitate email cauzate de reputația IP-ului partajat. Dacă emailurile tranzacționale, precum confirmările de comandă și resetările de parolă, ajung în spam, iar scorul de expeditor este afectat de un IP partajat pe care nu îl controlezi, un IP dedicat pe VPS îți redă controlul asupra livrabilității.

Ai nevoie să rulezi servicii custom. Un endpoint VPN, un runner CI/CD, o coadă de workeri în fundal sau un server WebSocket nu pot rula pe shared hosting. Acestea cer procese persistente și porturi de rețea pe care platformele shared le blochează.

Când să nu faci upgrade

Upgradeul la VPS nu este întotdeauna alegerea corectă. Nu face upgrade dacă:

• site-ul este un site mic de prezentare, portofoliu sau blog cu sub 10.000 de vizite pe lună și fără e-commerce; shared hostingul îl gestionează confortabil
• nu ai niciun interes pentru administrare Linux și nu îți permiți un plan VPS managed; un VPS unmanaged neîntreținut devine risc de securitate
• site-ul este lent din cauza imaginilor neoptimizate, a 50 de pluginuri active sau a unei teme umflate; mutarea unui site prost optimizat pe VPS îl transformă într-un site prost optimizat pe un server mai rapid
• bugetul chiar nu poate susține prețul unui VPS; un site lent, dar online, este mai bun decât un site rapid pe care nu îți permiți să îl ții pornit

Migrare: ce se rupe și cum repari

Mutarea de pe shared hosting pe VPS nu este o operațiune drag-and-drop. Iată cele mai comune lucruri care se rup la migrare și cum le previi sau le repari.

1. Căi hardcodate

Shared hostingul folosește de obicei public_html ca web root. Un VPS poate folosi /var/www/html sau o cale personalizată. Dacă wp-config.php, configurația unui plugin sau cron joburile conțin căi absolute hardcodate, se rup pe noul server. Caută în cod vechiul string de cale înainte de migrare.

2. Diferențe de versiune PHP

Shared hostul tău poate rula PHP 8.1. VPS-ul poate porni implicit cu PHP 8.3. PHP 8.1 ajunge la final de viață pe 31 decembrie 2025. Dacă site-ul sau pluginurile nu sunt compatibile cu PHP 8.2+, site-ul poate arunca erori fatale pe noul server. Testează pe versiunea PHP țintă înainte de cutover. PHP 8.3 sau 8.4 este minimul recomandat pentru proiecte noi și mentenanță modernă.

3. Extensii PHP lipsă

Shared hostingul oferă de obicei un set larg de extensii PHP: gd, imagick, mbstring, xml, zip, curl, intl, opcache. Un VPS minimal poate include doar extensiile de bază. WordPress are nevoie de mysqli, curl, mbstring, xml și zip cel puțin. Verifică php -m pe noul server și compară lista de extensii cu cea de pe vechiul host.

4. Probleme de permisiuni

Pe shared hosting, fișierele rulează adesea sub același utilizator care le deține. Pe un VPS, utilizatorul serverului web, de obicei www-data pe Debian sau Ubuntu, are nevoie de acces de citire la fișiere și acces de scriere în directoarele de upload și în wp-content. Ownershipul greșit cauzează erori 403 sau uploaduri eșuate. Remedierea tipică este:

chown -R www-data:www-data /var/www/your-site
find /var/www/your-site -type d -exec chmod 755 {} \;
find /var/www/your-site -type f -exec chmod 644 {} \;

5. Dependențe .htaccess când treci de la Apache la Nginx

Dacă shared hostul rulează Apache și VPS-ul rulează Nginx, fișierele .htaccess sunt ignorate. Regulile de permalink, redirecturile, protecția cu parolă și headerele custom nu mai funcționează. Trebuie să traduci regulile Apache în blocuri location Nginx. Configurația standard WordPress pentru Nginx este simplă, dar regulile custom cer traducere manuală.

6. Diferențe de collation în baza de date

Shared hosturile mai vechi pot folosi utf8mb3 sau collation legacy latin1. Instalările moderne de VPS pot folosi implicit utf8mb4_0900_ai_ci pe MySQL 8.0+. Importul unui dump cu collation nepotrivit poate produce probleme de encoding pentru conținut non-ASCII. Exportă cu --default-character-set=utf8mb4 și verifică collationul tabelelor importate.

7. Cron joburi care eșuează

Cron joburile de pe shared hosting folosesc adesea căi precum /usr/local/bin/php. Pe un VPS, binarul PHP poate fi la /usr/bin/php sau /usr/bin/php8.3. Cron joburile care apelează vechea cale eșuează în tăcere. Revizuiește toate intrările, actualizează căile și redirecționează outputul într-un fișier de log:

* * * * * /usr/bin/php /var/www/your-site/wp-cron.php >> /var/log/wp-cron.log 2>&1

8. Funcția mail() lipsește sau nu trimite corect

Shared hostingul oferă de obicei o funcție mail() funcțională prin MTA local. Un VPS minimal poate să nu aibă MTA instalat. Formularele de contact și emailurile WooCommerce nu se mai trimit. Remedierea este să instalezi Postfix sau să folosești un serviciu tranzacțional de email, precum SendGrid, Mailgun sau Postmark, împreună cu un plugin SMTP pentru WordPress. Configurarea corectă a unui MTA cu SPF, DKIM și DMARC nu este trivială. Un furnizor tranzacțional de email este de obicei mai simplu.

Strategie DNS TTL

Planifică migrarea pentru downtime minim. Cu 48 de ore înainte, scade TTL-ul DNS la 300 de secunde, adică 5 minute, pentru toate înregistrările A, AAAA și CNAME. Când actualizezi IP-ul la cutover, majoritatea resolverelor preiau schimbarea în aproximativ 5 minute. După ce migrarea este stabilă 24 până la 48 de ore, ridică TTL-ul înapoi la 3600 de secunde sau mai mult.

Certificate SSL

Pe un VPS, Let’s Encrypt oferă certificate SSL gratuite prin Certbot:

apt install certbot python3-certbot-nginx
certbot --nginx -d yourdomain.com -d www.yourdomain.com

Certbot configurează reînnoirea automată. Nu mai depinzi de programul AutoSSL al furnizorului de shared hosting.

Migrare email

Dacă găzduiești emailul pe shared hosting și îl muți pe VPS, planifică atent. Două abordări funcționează bine:

Abordarea IMAP sync. Folosește imapsync sau OfflineIMAP pentru a copia mailboxurile de pe serverul vechi pe cel nou înainte de cutover DNS. Asta păstrează structura folderelor și starea mesajelor citite.

Tranziție dual-MX. Setează noul server de mail de pe VPS ca MX cu prioritate mai mică în perioada de tranziție. Emailul ajunge la serverul disponibil. Sincronizează mailboxurile după cutover, apoi elimină MX-ul vechi. Asta reduce riscul de pierdere de email dacă sincronizarea ratează o fereastră.

Concluzia practică

Decizia de hosting nu este despre ce tehnologie este mai bună în abstract. Este despre ce constrângeri poți accepta și ce capabilități îți trebuie cu adevărat.

Alege shared hosting dacă rulezi un site mic, un portofoliu sau un blog cu sub 10.000 de vizite lunare, nu ai e-commerce, bugetul este strâns și nu ai interes pentru administrare de server. Shared hostingul este o alegere validă și practică pentru un procent mare de site-uri.

Alege VPS managed dacă site-ul crește, rulezi WooCommerce sau altă aplicație dinamică, ai nevoie de software custom sau de straturi de caching, vrei performanță predictibilă și preferi ca experții de infrastructură să gestioneze securitatea, actualizările și tuningul serverului. Păstrezi controlul asupra aplicației fără să devii administrator de sistem.

Alege VPS unmanaged dacă ai experiență de administrare Linux, vrei control complet asupra fiecărui parametru de configurare, poți gestiona singur securitatea, monitorizarea și backupurile și ești suficient de sensibil la cost încât să schimbi timpul tău pe o factură lunară mai mică. Fii sincer în privința competențelor și timpului disponibil. Un VPS unmanaged pe care nu îl întreții devine o vulnerabilitate.

Mediul de hosting îți afectează și performanța în motoarele de căutare. Viteza paginii, consistența uptime-ului și timpul de răspuns al serverului influențează modul în care motoarele de căutare crawlează și evaluează site-ul. Pentru o analiză mai detaliată a implicațiilor SEO, citește articolul nostru despre dacă mediul de găzduire influențează SEO-ul.

Ce să faci mai departe

Dacă shared hostingul se potrivește nevoilor tale actuale, vezi planurile de găzduire web ServerSpan pentru site-uri mici, cu suport uman și infrastructură fiabilă.

Dacă VPS-ul este pasul corect pentru site-ul sau magazinul tău în creștere, vezi opțiunile de găzduire VPS ServerSpan. Planurile noastre VPS managed includ administrare de server, hardening de securitate, monitorizare proactivă și suport din partea sysadminilor certificați care gestionează infrastructura ca tu să te poți concentra pe business.

Dacă nu ești sigur ce variantă se potrivește situației tale, contactează echipa noastră. ServerSpan oferă atât shared hosting, cât și VPS, deci recomandarea se bazează pe cerințele tale reale. Poți adăuga și tagul #noai în cererea de suport dacă vrei un răspuns direct de la un om, fără introduceri automate.

Pentru a înțelege mai bine cum abordează ServerSpan suportul de hosting, vizitează pagina De ce ServerSpan.