VPS, managed hosting of dedicated: wat je in 2026 eigenlijk kiest

Van buitenaf lijken alle drie de modellen hetzelfde: je logt in, je ziet een Linux prompt, je draait je applicatie. Onder de motorkap is de afspraak die je hebt gemaakt heel anders.

Bij een VPS huur je een deel van een fysieke machine. De fysieke host en virtualisatielaag zijn van de provider. Jij beheert het guest operating system en alles daarboven. De exacte kernelgrens hangt af van het virtualisatiemodel, en dat doet ertoe wanneer kwetsbaarheden op kernelniveau verschijnen.

Bij managed hosting huur je een resultaat. De provider beheert het operating system, de runtime, vaak de database, en het grootste deel van de tooling eromheen. Jij levert de applicatie en de content. Het control panel, cPanel, Plesk, DirectAdmin of een eigen panel, is de zichtbare laag. Maar het echte product is het operationele team erachter.

Bij een dedicated server huur je de hardware zelf. Het operating system, de kernel, de storage layout en vaak delen van de boot- en remote-managementconfiguratie vallen onder jouw controle. De exacte grens hangt af van de provider en het contract. De provider levert stroom, netwerk, fysieke beveiliging en de afgesproken managed laag. De rest ligt bij jou, tenzij je daarbovenop een managed dedicated tier afneemt.

Geen van deze modellen is in abstracte zin beter. Het zijn verschillende afspraken voor verschillend werk. De fout die mensen maken is niet dat ze het verkeerde model kiezen. Het is dat ze het gekozen model behandelen alsof het een van de andere modellen is.

Een VPS geeft je een Linux-machine waarop je via SSH kunt inloggen, voorspelbare maandelijkse kosten, snelle provisioning en een echt operating system om echte workloads op te draaien. Voor de meeste productiewebsites, interne tools, stagingomgevingen, API’s met lager verkeer en SaaS-teams op kleine schaal is dit het juiste antwoord, geen compromis.

Wat je krijgt met een VPS:

• Root op je eigen operating system, met de vrijheid om te installeren wat je nodig hebt.
• Voorspelbare, grotendeels vaste maandelijkse kosten.
• Provisioning in minuten in plaats van dagen, plus de mogelijkheid om instances toe te voegen of te vergroten wanneer de load verandert.
• Een duidelijke verantwoordelijkheidsgrens boven de virtualisatielaag: alles wat jij installeert, beheer jij.

Wat je deelt met andere tenants:

• De fysieke host en de virtualisatielaag. Wanneer er een host-level kwetsbaarheid ontstaat, patcht de provider de host. Binnen de guest patch jij nog steeds je eigen operating system.
• Fysieke resources tijdens piekbelasting. De meeste VPS-platformen beheren dit goed, maar een noisy neighbor kan nog steeds zichtbaar worden als variatie in I/O latency of CPU steal time tijdens een verkeerspiek.
• De blast radius van een host compromise. Als de hypervisor of hostlaag wordt gecompromitteerd, kan iedere tenant daarop binnen scope vallen.

Dat is geen argument tegen VPS. Het is de trade-off waarvoor je hebt gekozen: lagere kosten en minder verantwoordelijkheid voor hardware, in ruil voor een laag van de stack die je niet zelf beheert. Het punt is dat je moet weten welke trade-off je hebt genomen, zodat je de machine daar ook naar beheert.

Bij een VPS begint jouw patchverantwoordelijkheid binnen het guest operating system. Je voert security updates uit, je reboot wanneer je guest kernel dat nodig heeft, en je houdt de statuspagina van de provider in de gaten voor host-level maintenance waar je niet omheen kunt. De Linux kernel-CVE die begin mei verscheen, is het duidelijkste voorbeeld: elke VPS guest had aandacht nodig binnen het operating system, terwijl providers waar nodig ook de host- en virtualisatielagen moesten aanpakken. De operator en de provider zaten samen op het patchpad.

Managed hosting is het model waarbij de provider de server beheert, zodat jij dat niet hoeft te doen. In de klassieke vorm, het cPanel- of Plesk-control panel, de gedeelde mailserver, de one-click WordPress-installer, heeft dit model een hele generatie kleine bedrijven, agencies en indie developers geholpen die geen sysadmin wilden zijn. Dat is nog steeds de kernbelofte: jij uploadt de site, de provider houdt hem draaiend.

Wat “managed” precies dekt, verschilt per provider. Een nuttige checklist wanneer je er een beoordeelt:

• Operating system patching: wie voert patches uit, volgens welk schema, en hoe snel wanneer een CVE wordt toegevoegd aan een lijst met bekende actief misbruikte kwetsbaarheden?
• Control-panel patching: welke versies worden gevolgd, en hoe wordt een zero-day afgehandeld voordat er een upstream patch beschikbaar is?
• Backups: hoe vaak worden ze gemaakt, waar worden ze opgeslagen, hoe start je een restore, en hoe worden restores getest?
• Monitoring en incident response: wie bewaakt wat, en wat is de daadwerkelijke responstijd bij een bevestigd incident?
• Supportgrens: waar eindigt “managed” en waar begint “jouw applicatie”?

De eerlijke lezing van managed hosting is dat de waarde in het operationele team zit, niet in het control panel. Twee providers kunnen dezelfde software leveren en daarbovenop compleet verschillende producten draaien. De een heeft een SOC, een gedocumenteerd incident playbook en een trackrecord van het patchen van kritieke CVE’s op de dag dat een werkende exploit publiek is. De ander heeft een helpdesk en een forum. Beiden verkopen “managed hosting.” De taak bij evaluatie is ontdekken welke van de twee je koopt.

Wat managed hosting heel goed doet, als je een serieuze operator kiest: het haalt de dagelijkse administratieve last van je bord, geeft je één aanspreekpunt wanneer iets stukgaat, en verandert server operations in voorspelbare maandelijkse kosten in plaats van een onvoorspelbare tijdvreter. Dat is een echt product, en voor veel kopers is het het juiste product.

Het wordt ongemakkelijk wanneer de grens onduidelijk is. “Managed” betekent niet “geïsoleerd.” Als er een kritieke authentication-bypass kwetsbaarheid in het control panel zelf ontstaat, is iedere server die dat panel draait blootgesteld totdat de provider patcht. De klant kiest het patchvenster niet. Dat hoort bij de afspraak. De manier om daarmee te leven is een provider kiezen waarvan je patchcadans en disclosuregewoonten kunt controleren, niet doen alsof die afhankelijkheid niet bestaat.

Een dedicated server is de eenvoudigste afspraak van de drie om uit te leggen, en de meest veeleisende om te beheren. De hardware is aan jou toegewezen. Geen tenant aan de andere kant van de hypervisor, omdat er geen hypervisor is tenzij jij er een installeert. Geen gedeelde guestomgeving, geen gedeelde fysieke resources, geen scheduling overhead van een virtualisatielaag.

Dat betekent dat je controle hebt, of contractueel controle kunt krijgen, over:

• Het operating system en de kernel, inclusief hardeningkeuzes die niet altijd mogelijk zijn in gedeelde omgevingen.
• Het bootpad en de platformconfiguratie, afhankelijk van het servermodel en het beleid van de provider.
• Out-of-band management access, idealiter met IPMI- en BMC-verkeer op een gescheiden managementnetwerk dat niet bereikbaar is vanaf het publieke internet.
• Storage layout, RAID-configuratie en disk encryption keys.
• Patchtiming. Wanneer een kritieke CVE verschijnt, bepaal jij wanneer de server reboot.

Dat laatste verschil deed er de afgelopen maand het meest toe. Op een dedicated machine die jij beheert, is het toepassen van de kernelpatch voor een privilege-escalation CVE een maintenance window dat jij plant. Je wacht niet op de hostoperator, je hebt geen gedeelde blast radius, en er is geen tweede-orde outage omdat de host reboot en jouw guest mee moet rebooten.

De prijs van die controle is verantwoordelijkheid. Patching, monitoring, backups, incident response, capacity planning, tenzij je daarbovenop een managed tier koopt, ligt het allemaal bij jou. Dedicated is niet het juiste antwoord voor een team dat geen echte operationspraktijk heeft, of die niet wil opbouwen. Het is het juiste antwoord wanneer je workload daadwerkelijk voordeel heeft van dieper stackeigenaarschap: stabiele basisbelasting, latencygevoelige paden, isolatie-eisen vanuit beleid of compliance, of een securitymodel waarin “de kernel is van mij” een harde eis is.

Als je geen van die drivers hebt, is dedicated overhead. Heb je ze wel, dan is het het enige model dat je de hendels geeft die je nodig hebt.

In de praktijk overlappen de drie categorieën op manieren die vergelijkingspagina’s niet altijd duidelijk maken.

Managed VPS bestaat. Unmanaged dedicated ook. Net als een dedicated server waarop je zelf een hypervisor draait en VPS-slices verhuurt aan interne tenants. De categorienaam vertelt waar je begint. Hij vertelt niet de volledige afspraak.

Drie vragen snijden door de marketing heen:

• Wie beheert de kernel? Als het antwoord “jij” is, beheer jij de guest kernel. Als het antwoord “de provider” is, ben je voor die laag afhankelijk van de provider. Het exacte antwoord hangt af van het virtualisatiemodel.
• Wie voert de patch uit? Loop door wat er gebeurt op zaterdagochtend wanneer een kritieke CVE verschijnt. Wiens pager gaat af? Wiens change ticket wordt aangemaakt?
• Wiens blast radius is die van jou? Als de host wordt gecompromitteerd, val jij dan binnen scope? Als het control panel wordt gecompromitteerd, val jij dan binnen scope? Eerlijke antwoorden hierop zijn nuttiger dan featurelijsten.

Zodra je die drie vragen kunt beantwoorden, kun je het grootste deel van de ruis in vergelijkingstabellen negeren. Het onderliggende product heeft een vorm, ongeacht welk label er op de marketingpagina staat.