Shared hosting of VPS: wat is de juiste keuze?

Shared hosting versus VPS: het korte antwoord

Shared hosting versus VPS is geen vraag van snelheid. Bij shared hosting huurt u een account op een machine die door iemand anders wordt geconfigureerd, gepatcht en gedeeld met honderden klanten. Bij een VPS (virtual private server) huurt u een volledig besturingssysteem met root-toegang, waardoor u zelf installeert wat u wilt en ook zelf repareert wat u kapotmaakt.

Drie zaken maken het werkelijke verschil. U heeft root-toegang of u heeft die niet. Uw geheugen is aan u toegewezen of wordt geleend uit een gedeelde pool. En wanneer de server midden in de nacht niet meer reageert, lost de host het op of doet u dat zelf. Alles in een vergelijkingstabel vloeit voort uit deze drie punten.

Als uw site bestaat uit pagina's, afbeeldingen en een contactformulier, dan is shared hosting het juiste antwoord en zijn de kosten lager. Als uw site een programma vereist dat blijft draaien terwijl er geen bezoekers zijn, dan heeft u een VPS nodig.

Wat shared hosting u daadwerkelijk biedt

Eén Linux-server draait gelijktijdig vele klantaccounts. Elk account bestaat uit een home-directory met een document root, een database en een mailbox. Eén enkele webserver, meestal Apache of LiteSpeed, bedient alle websites op de machine. U krijgt een configuratiescherm in plaats van een shell-prompt. U beschikt niet over root-toegang, waardoor u geen pakketten kunt installeren, poorten kunt openen of achtergrondservices kunt starten.

De meeste shared hosts draaien CloudLinux, dat elk account in een eigen container plaatst met een harde limiet op processortijd en het aantal processen dat u tegelijkertijd mag draaien. Het overschrijden van de proceslimiet maakt uw site niet traag. De server geeft in plaats daarvan een foutpagina weer met de melding 508 Resource Limit Is Reached. Die pagina betekent dat uw eigen account zijn plafond heeft bereikt, en niet dat een buurman uw resources verbruikt.

Deze afweging is bewust. U levert controle in, en in ruil daarvoor patcht de host de kernel, werkt PHP bij, vernieuwt het certificaat en maakt dagelijks een back-up. Voor een groot aantal websites is dat een goede deal.

Wat een VPS u daadwerkelijk biedt

Een VPS is een virtuele machine die op een hostserver draait. Onder KVM, de hypervisor achter de meeste Linux VPS-abonnementen, start uw instantie een eigen kernel en beschikt deze over een eigen IP-adres, een eigen firewall en een eigen init-systeem. sudo werkt. apt install werkt. Een programma dat u via systemd start, blijft draaien nadat u bent uitgelogd, start opnieuw op na een crash en komt terug na een reboot.

Diezelfde root-toegang is de reden waarom de beveiliging van de machine uw verantwoordelijkheid wordt. Niemand anders houdt toezicht. Het scala aan zaken dat mensen op een VPS draaien is om precies deze reden breed: de machine doet alles wat een Linux-server kan doen.

Verschil 1: root-toegang en wat dit mogelijk maakt

Root is het verschil dat alle andere verschillen veroorzaakt. Met root-toegang installeert u elk pakket uit de distributie, bindt u elke poort, schrijft u een systemd-unit, leest u elk logbestand op de machine en wijzigt u kernelinstellingen met sysctl. Zonder root-toegang bent u beperkt tot de lijst die het paneel biedt: een PHP-versiekiezer, een vaste set extensies en een formulier voor cron-jobs.

Op een VPS kunt u de machine altijd vragen wat er luistert:

ss -ltnp

Elke regel is een open socket met het proces dat deze bezit. Een service die niet is gestart, verschijnt daarom als een ontbrekende regel. Bij shared hosting heeft deze vraag geen antwoord, omdat poort 80 en 443 toebehoren aan de webserver van de host en niets wat u schrijft deze kan overnemen.

Verschil 2: toegewezen geheugen versus geleend geheugen

Shared hosting wordt verkocht met de aanname dat slechts enkele accounts op hetzelfde moment actief zijn. Het geheugen in de machine is een gedeelde pool en het aandeel van uw account is een limiet in plaats van een reservering. Wanneer uw aandeel op is, worden PHP-processen beëindigd en krijgen bezoekers een 500- of 508-foutmelding.

Op een VPS behoort het geheugen in uw abonnement toe aan uw instantie. free -m rapporteert dit en geen enkel proces buiten uw virtuele machine kan dit geheugen opeisen.

Processortijd is de eerlijke uitzondering. De meeste VPS-abonnementen delen fysieke cores tussen gasten en u kunt dit zelf meten:

vmstat 1 5

De kolom st staat voor steal time: het aandeel van de tijd dat uw virtuele processor klaar was om te draaien, terwijl de fysieke core aan een andere gast was toegewezen. Een constante waarde van enkele procenten is normaal. Een aanhoudend getal in de dubbele cijfers betekent dat de host overbezet is; dit is een cijfer dat u kunt aanhalen in een supportticket. Bij shared hosting bestaat er geen equivalente meting, omdat elk hulpmiddel dat dit zou kunnen tonen root-rechten vereist. Opslag gedraagt zich op dezelfde manier, en daarom is het schijftype achter een VPS-abonnement van belang, en is het de moeite waard om een nieuwe VPS zelf te meten in de eerste week in plaats van te vertrouwen op de verkooppagina.

Verschil 3: wie is verantwoordelijk bij storingen

Bij shared hosting is de hosteigenaar verantwoordelijk voor het besturingssysteem, de webserver, de PHP-build, de certificaten en de dagelijkse back-ups. Wanneer de machine niet meer reageert, opent u een ticket en werkt er al iemand aan de oplossing. De kosten hiervan vormen de keerzijde van dezelfde regel: u kunt hen niet vragen om software te installeren die zij niet ondersteunen.

Op een unmanaged VPS is de provider eigenaar van de hypervisor, het netwerk en de stroomvoorziening. Alles vanaf de kernel en hoger is uw verantwoordelijkheid. Beveiligingsupdates, de firewall, back-ups, certificaatvernieuwing en monitoring zijn allemaal uw werk, en de supportafdeling zal niet inloggen om uw webserverconfiguratie te debuggen. Houd hier vanaf de eerste dag rekening mee: de eerste tien minuten op een nieuwe VPS, daarna een firewall die u begrijpt, automatische beveiligingsupdates en back-ups die u ten minste één keer heeft hersteld.

Wanneer shared hosting de juiste keuze is

Een brochure-website is het duidelijkste voorbeeld: enkele pagina's, afbeeldingen, een contactformulier, wellicht WordPress met een caching-plugin, en een paar duizend bezoeken per dag. Geen achtergrondtaken. Geen ongebruikelijke runtime. Niets dat tussen verzoeken door in het geheugen moet blijven. Shared hosting voldoet uitstekend voor een dergelijke site, kost minder dan elke VPS en legt het onderhoud bij mensen die dit fulltime doen. Het verplaatsen naar een VPS levert niets op en voegt een taak toe die u voorheen niet had.

Er is een tweede scenario dat minder aandacht krijgt. Als niemand aan uw kant logbestanden wil lezen of apt upgrade wil uitvoeren, is shared hosting de veiligere keuze. Een ongepatchte VPS met een open databasepoort is een slechter resultaat dan een gedeeld account dat door een professional up-to-date wordt gehouden. Controle is alleen een voordeel als iemand er ook daadwerkelijk gebruik van maakt.

Signaal 1: u heeft een programma nodig dat blijft draaien

Een daemon is een programma dat in het geheugen blijft en wacht op werk: een API, een chatbot, een queue worker of een gameserver. Shared hosting voert uw code alleen uit wanneer er een verzoek binnenkomt. Alles wat u vanuit een SSH-sessie (secure shell) laat draaien, wordt beëindigd, omdat een langlopend proces meetelt voor het proceslimiet van het account.

Op een VPS wordt hetzelfde programma een systemd unit:

sudo systemctl enable --now myapp
systemctl status myapp

systemctl status hoort Active: active (running) met een proces-ID weer te geven. Als het Active: failed (Result: exit-code) weergeeft, staat de reden in journalctl -u myapp -n 50; dit toont de output van het programma op het moment dat het stopte. Restart=always in het unit-bestand zorgt ervoor dat het programma na een crash opnieuw opstart, en enable zorgt voor herstel na een reboot. Het schrijven van systemd services en timers is de eerste VPS-vaardigheid die het waard is om goed te leren.

Signaal 2: u heeft een runtime nodig die het paneel niet aanbiedt

Het paneel biedt u een lijst aan. Als uw applicatie een taalversie buiten die lijst vereist, een bibliotheek die gecompileerd moet worden, ffmpeg, een headless browser of een database die geen MySQL is, dan biedt shared hosting hiervoor geen ruimte. Voor het installeren van software is root-toegang vereist, en het account beschikt niet over een compiler of development headers. Hierdoor mislukt een build voordat er resultaat wordt gegenereerd.

Op een VPS installeert u dit met apt install, of u draait het in een container om de host schoon te houden. Docker Compose op een VPS is de gebruikelijke methode zodra de applicatie uit meer dan één onderdeel bestaat.

Teken 3: uw cron job moet op tijd worden uitgevoerd

Shared hosts accepteren cron jobs via een formulier en hanteren een minimuminterval, meestal vijf of vijftien minuten. Een taak die de processorlimiet van het account overschrijdt, wordt voortijdig beëindigd. Dit gebeurt zonder foutmelding, omdat er niets wordt geschreven naar een logbestand dat u mag inzien.

Op een VPS accepteert crontab -e elk schema dat u opstelt, en een systemd timer is nog beter:

systemctl list-timers
journalctl -u cron -n 20

list-timers toont de volgende uitvoering en het laatste resultaat voor elke timer, en het cron-logboek toont elk commando zodra dit wordt gestart. Wanneer een taak niet wordt uitgevoerd, kunt u vaststellen of deze nooit is gestart of is gestart en mislukt. Dat onderscheid vormt het grootste deel van het debuggen van een geplande taak.

Signaal 4: uw buren kosten u responstijd

Het symptoom is specifiek. Dezelfde pagina, zonder wijzigingen in uw code, reageert 's nachts snel en om zeven uur 's avonds traag. Meet dit vanaf uw eigen machine voordat u iemand de schuld geeft:

for i in $(seq 1 20); do curl -o /dev/null -s -w '%{time_starttransfer}\n' https://example.com/; sleep 5; done

time_starttransfer is de tijd tot de eerste byte van het antwoord, in seconden. Als de twintig getallen dicht bij elkaar liggen, is de server niet het probleem en ligt de oplossing in uw code of uw database-queries. Als ze om 03:00 uur stabiel zijn en tijdens piekuren met enkele honderden milliseconden schommelen, deelt u een drukke machine met accounts die u niet kunt zien. Dat is de enige trigger die u niet kunt verhelpen met betere code, omdat de oorzaak zich aan de andere kant van de accountgrens bevindt.

Wat de overstap daadwerkelijk kost

Dit zijn de gebruikelijke geadverteerde prijzen per augustus 2026 voor het kleinste abonnement in elke categorie. Beschouw deze als een indicatie in plaats van een offerte en controleer de actuele prijs voordat u tot aanschaf overgaat.

[
  {
    "plan": "Shared hosting",
    "first_term_usd": 3,
    "renewal_usd": 12
  },
  {
    "plan": "VPS, 1 vCPU 1 GB",
    "first_term_usd": 5,
    "renewal_usd": 6
  },
  {
    "plan": "VPS, 2 vCPU 4 GB",
    "first_term_usd": 12,
    "renewal_usd": 15
  },
  {
    "plan": "Managed VPS, 2 vCPU 4 GB",
    "first_term_usd": 25,
    "renewal_usd": 30
  }
]

Het prijsverschil loopt uiteen van 3 tot 5 Amerikaanse dollar per maand, maar dit getal is niet doorslaggevend. Shared hosting adverteert met een instaptarief waarvoor doorgaans één tot drie jaar vooruitbetaald moet worden, waarna het abonnement wordt verlengd voor ongeveer 12 dollar. Vergelijk de verlengingsprijs met de verlengingsprijs en het beeld verandert: 12 dollar voor het shared account tegenover 6 dollar voor een instap-VPS.

Wees voorzichtig met deze vergelijking, aangezien de specificaties niet gelijk zijn. Een VPS met 1 vCPU en 1 GB RAM draait de webserver en de database op één kleine machine, wat krap is voor WordPress zodra er daadwerkelijk verkeer binnenkomt. Een eerlijke vergelijking met een verlengd shared hosting-abonnement is de 2 vCPU, 4 GB-variant van ongeveer 15 dollar. De werkelijke meerprijs is dus slechts enkele dollars per maand, geen veelvoud.

De grootste kostenpost staat nooit op de factuur. Een VPS vereist een uur aan installatietijd, enkele minuten per maand voor updates en de avond die u kwijt bent wanneer er voor het eerst iets kapotgaat. Reken dit door tegen uw eigen uurtarief en het prijsverschil is snel verdwenen. Wat een VPS in de praktijk kost behandelt de verschillende groottes in meer detail.

Een website verhuizen van shared hosting zonder verkeer te verliezen

1. Verlaag een dag van tevoren de DNS (domain name system) TTL (time to live) voor het domein naar 300 seconden, zodat de overstap binnen minuten in plaats van uren effect heeft.
2. Bouw de nieuwe server op en zorg dat de site werkt op het IP-adres voordat u de DNS aanpast.
3. Kopieer de bestanden, dump vervolgens de database en herstel deze op de nieuwe server.
4. Test via het hosts-bestand van uw laptop, dat het domein alleen voor uw machine naar het nieuwe IP-adres verwijst.
5. Vraag het TLS (transport layer security) certificaat aan op de nieuwe server, wijzig het A-record en houd het shared account nog een week actief.

dig example.com A +noall +answer
rsync -avz ~/public_html/ deploy@203.0.113.10:/srv/www/example.com/
mysqldump --single-transaction -u dbuser -p dbname > site.sql

dig toont de TTL in de tweede kolom van het antwoord, zodat u kunt bevestigen dat de lagere waarde actief is voordat u iets wijzigt. --single-transaction maakt een consistente snapshot zonder de tabellen te vergrendelen; dit is van belang als de oude site nog bestellingen verwerkt terwijl u aan het werk bent. Zorg op de nieuwe server dat certificaten dezelfde dag nog werken: Let's Encrypt op Ubuntu met nginx kost enkele minuten zodra het DNS-record naar de server wijst.

Resources zonder de verantwoordelijkheid

Als de vier signalen uw site beschrijven, maar het onderhoud u niet aanspreekt, is een managed VPS de tussenoplossing. U behoudt het toegewezen geheugen en de root-toegang, terwijl de provider het patchen, de monitoring en meestal een beheerpaneel verzorgt. De bovenstaande tabel plaatst de kosten op ongeveer 30 dollar tegenover 15 voor een onmanaged VPS van dezelfde omvang. Het prijsverschil koopt de aandacht van een ander op het moment dat de server 's nachts niet meer reageert.

De keuze tussen een managed en onmanaged VPS is de juiste volgende stap als dit u aanspreekt. Als u daarentegen al een drukke VPS beheert en de 'steal time' tijdens piekuren nog steeds problematisch is, is de volgende stap een dedicated server zonder enige buren.

FAQ

Is een VPS sneller dan shared hosting?

Niet automatisch. Een rustige shared server kan sneller zijn dan een VPS met 1 vCPU bij het laden van een enkele WordPress-pagina. Wat een VPS u biedt, is consistentie: het geheugen in uw abonnement is voor u gereserveerd. De responstijd hangt daardoor af van uw code in plaats van van het drukste account op de machine. Als uw pagina's zowel om 03:00 uur als om 19:00 uur traag zijn, ligt de oorzaak bij uw code of uw database-queries. Het verplaatsen van dezelfde code naar een VPS lost dat probleem niet op.

Kan ik een Node.js- of Python-applicatie draaien op shared hosting?

Soms, maar alleen binnen nauwe grenzen. Sommige controlepanelen starten een applicatie voor u via Passenger, die draait zodra er een verzoek binnenkomt. U kunt geen eigen poort binden, omdat de webserver van de host poort 80 en 443 beheert. U kunt geen worker in het geheugen houden tussen verzoeken door, omdat de proceslimiet van het account langlopende processen beëindigt. Een bot, een queue-worker of een websocket-server vereist een VPS.

Moet ik Linux kennen om een VPS te beheren?

Voor een unmanaged VPS wel. U heeft SSH-keys, een firewall, updates, back-ups en de gewoonte om logs te lezen nodig. Reken op een uur voor de initiële configuratie en daarna enkele minuten per maand. Als u dit werk niet wilt doen, biedt een managed abonnement dezelfde resources, maar neemt de provider het onderhoud op zich. Dit is de afweging die wordt besproken in managed versus unmanaged VPS hosting.

Gaat mijn site offline tijdens de verhuizing van shared hosting naar een VPS?

Niet als u eerst de DNS TTL verlaagt en beide accounts actief houdt. Stel de TTL een dag van tevoren in op 300 seconden, kopieer de bestanden en de database, test de nieuwe server via het hosts-bestand van uw laptop en wijzig daarna het A-record. Gedurende enkele minuten zullen sommige bezoekers de oude server bereiken en anderen de nieuwe; houd het shared account daarom nog een week actief. Zet de site in read-only modus tijdens de laatste database-dump, of accepteer dat gegevens die in dat tijdsbestek worden geschreven, verloren gaan.