Gameserver hosting op bare metal: waarom dedicated hardware wint

Eerst het antwoord: waarom bare metal wint voor gameservers

Een gameserver is geen webserver. Hij draait één simulatielus die de hele wereld op een vaste klok vooruit stapt: natuurkunde, entiteiten, spelers, alles, in volgorde, op één thread. Minecraft draait die lus 20 keer per seconde, wat 50 milliseconden geeft om elke tick af te ronden. Mis die deadline en de tick loopt uit, de server raakt achterop, en spelers voelen dat als rubber-banding, vertraagde hits en lagpieken. De cijfers die bepalen of een gameserver goed aanvoelt zijn dus snelheid per core en consistente timing, niet het aantal cores of doorvoer.

Dat is het hele argument voor bare metal in één alinea. Een gedeelde VPS zet de scheduler van een hypervisor tussen jouw tick-lus en de fysieke CPU. Wordt een buur op dezelfde host druk, dan wacht jouw thread op zijn beurt, en die wachttijd landt als jitter precies op het moment dat een tick op tijd af moet zijn. Bare metal geeft je de hele machine, zonder dat iets de CPU onder je vandaan plant. Voor een server die alleen voor vrienden is en het grootste deel van de dag stilligt, maakt dit allemaal niets uit en volstaat een VPS. Voor alles met een vol spelersaantal en een krap tick-budget wint de fysieke machine, omdat die het ene ding wegneemt dat een tick-lus niet kan verdragen: iemand anders die beslist wanneer hij mag draaien.

Dit artikel behandelt:

• wat "bare metal" betekent naast een VPS en een beheerd gameserver-panel
• waarom een gameserver-workload zich anders gedraagt dan de webapps waarvoor de meeste hostingadviezen geschreven zijn
• waarom hoge klokfrequentie wint van coreaantal voor de meeste titels, en de gevallen waarin veel cores wél hun plek verdienen
• hoeveel RAM populaire servers werkelijk nodig hebben, met de publieke cijfers voor elk
• opslag, back-ups en de DDoS-realiteit van een game-IP op het publieke internet
• een controlepanel als Pterodactyl of de Pelican-fork ervan draaien op je eigen hardware
• de eerlijke lijst van momenten waarop bare metal de moeite niet waard is

Voor het diepere timing-argument gaan twee bijbehorende artikelen verder dan dit overzicht: bare metal versus virtuele machines zet cijfers op het verschil, en waarom latency ertoe doet voor gameservers behandelt de netwerkkant.

Wat "bare metal" eigenlijk betekent

Er zijn drie manieren om een gameserver te draaien, en het verschil zit in wie de CPU controleert.

Beheerde gameserver-hosting. Je huurt een slot voor één game, de provider beheert de hardware en een controlepanel, en jij krijgt een webpagina met een startknop en een config-editor. Het is de snelste manier om een server live te krijgen en het minste dat je ooit over de machine hoeft na te denken. Je krijgt ook precies de CPU, RAM en het netwerk die de provider voor een slot heeft bepaald, op hardware die gedeeld wordt met de slots van andere klanten.

Een VPS. Je huurt een virtuele machine: een deel van een fysieke host, uitgesneden door een hypervisor zoals KVM of VMware, of door een containerlaag zoals OpenVZ of LXC. Je krijgt root en kunt alles installeren. Wat je niet krijgt is de hele CPU. De scheduler van de host geeft je virtuele cores echte cycli zodra die vrij zijn, en "zodra die vrij zijn" hangt af van wat elke andere tenant op de machine aan het doen is.

Bare metal. Je huurt de hele fysieke server. Geen hypervisor, geen andere tenants, geen scheduler die beslist wanneer jouw proces draait. De klokfrequentie op het specsheet is de klokfrequentie die jouw tick-lus krijgt, de hele tijd. Je bent ook eigenaar van alles wat verder bij een echte machine hoort: het volledige RAM, de NVMe, de netwerkpoort, en het patchen en de back-ups die een beheerde host anders voor je had gedaan.

De reden dat dit onderscheid meer uitmaakt voor games dan voor de meeste workloads komt neer op die scheduler, en op hoe een gameserver een CPU sowieso al gebruikt.

Waarom een gameserver-workload ongebruikelijk is

De meeste serverworkloads zijn doorvoermachines. Een webserver verwerkt duizend onafhankelijke requests over elke core die je hem geeft; een database verspreidt queries over connecties. Voeg cores toe en ze gaan sneller. Een gameserver doet het tegenovergestelde. Hij laat één gedeelde wereldstatus in strikte volgorde vooruitgaan, want waar entiteit B deze tick naartoe beweegt hangt af van waar entiteit A deze tick naartoe bewoog, dus het werk kan niet over cores worden verdeeld zonder dat de simulatie zichzelf tegenspreekt. De meeste gameservers draaien hun hoofdlus daarom op één thread en leunen op een handvol extra threads, alleen voor bijzaken zoals netwerken, chunk-generatie en file I/O.

Die ene lus draait tegen een deadline aan. Minecrafts 20 ticks per seconde is een budget van 50 ms per tick; andere engines kiezen hun eigen snelheid, maar de vorm is hetzelfde. Past het werk van een tick binnen zijn budget, dan houdt de server de volle tickrate aan en voelt de wereld responsief. Past het niet, dan loopt de tick uit, begint de volgende te laat, en zakt de server ofwel naar een lagere effectieve tickrate of stapelt hij lag op tot hij het weer heeft ingehaald. Spelers ervaren dat als hit registration die misgaat en entiteiten die teleporteren. De metriek die dit voorspelt is niet de gemiddelde CPU-belasting. Het is de worst-case tijd om een tick af te ronden, en worst-case timing is precies wat een gedeelde scheduler onvoorspelbaar maakt.

• Latency-gevoeligheid. Een tick die op tijd klaar is, is verspild als het pakket 120 ms nodig heeft om de speler te bereiken. Gameservers geven veel meer om round-trip time en routekwaliteit dan om ruwe bandbreedte, en daarom telt de locatie van het datacenter en network peering net zo zwaar als de CPU. Het latency-artikel werkt het round-trip-budget per genre uit.
• Piekbelasting. De belasting is niet gelijkmatig. Een raid op een Rust-basis, een redstone-constructie die afgaat, veertig spelers die tegelijk op één plek landen: de tick die dit allemaal moet simuleren is degene die het budget opblaast. Je dimensioneert voor de piek, niet voor het gemiddelde.

Jitter, niet doorvoer, is de vijand. Een server die elke tick in 20 ms afrondt, op één stall van 80 ms per minuut na, voelt slechter aan dan een server die stabiel 35 ms doet, want die stall is precies het moment waarop een speler van achter dekking wordt neergeschoten. Dit is de belangrijkste reden dat gedeelde tenancy tegen gameworkloads ingaat, en het is het onderwerp van bare metal versus virtuele machines.

Klokfrequentie wint van cores, tot het niet meer zo is

De praktische conclusie uit die single-threaded lus: voor één gameserver wint een CPU met minder, snellere cores altijd van een CPU met veel trage cores. Onze sizing-gids voor servers stelt het bot: vierenzestig trage cores verliezen van acht snelle, en noemt dat de meest voorkomende sizing-fout bij gameservers. Een moderne chip voorbij 5 GHz met sterke prestaties per core, zoals de Ryzen 9950X in onze gameserver-configuraties op 4.3 GHz base en 5.7 GHz boost, rondt een zware Minecraft- of Rust-tick eerder af dan een 64-core serverplatform op 2.5 GHz, ongeacht hoeveel cores die grote chip heeft, omdat de lus er toch maar één tegelijk kan gebruiken.

Cores zijn daarom niet nutteloos. Ze betalen zich uit zodra je niet langer één server draait, maar er veel tegelijk:

• Meerdere instances. Tien Minecraft-servers, of een Rust-server plus een ARK-cluster plus een paar Valheim-werelden, zijn tien-plus onafhankelijke single-threaded lussen. Nu is coreaantal weer doorvoer: elke instance krijgt zijn eigen core of twee en ze draaien parallel.
• Een controlepanel. Pterodactyl of AMP draaien om veel gameservers op één machine te hosten is per definitie het veel-cores-geval; hierover verderop meer.
• Nevenwerk. Zelfs een enkele server gebruikt extra threads voor chunk-generatie, compressie en back-ups. Marge naast de hoofdcore houdt dat werk buiten het kritieke pad.

De regel is dus kort: snelle cores voor één server, meer cores voor velen. Hoge klokfrequentie is de standaard, en coreaantal is wat je toevoegt wanneer de taak van de machine is om een vloot te draaien in plaats van één wereld.

Hoeveel RAM populaire servers werkelijk nodig hebben

RAM is het gebied waar publieke cijfers bestaan, dus hier zijn ze, gehaald uit de eigen richtlijnen van elke game en de consensus onder operators daaromheen. Behandel ze als cijfers per instance, en onthoud dat plugins, mods en spelersaantal ze allemaal omhoog duwen.

De Minecraft-cijfers komen voort uit hoe de Java-server geheugen gebruikt. PaperMC's tuning-richtlijnen raden aan om te draaien met Aikar's flags, een set G1-garbage-collector-argumenten, en de initiële en maximale heap op dezelfde waarde te zetten zodat de JVM nooit midden in een tick van grootte verandert. Hun eigen opmerking is het herhalen waard: een goed afgestelde heap van 6 GB presteert beter dan een slecht afgestelde van 12 GB, dus meer RAM is hier niet automatisch meer prestatie. View distance is de vermenigvuldigingsfactor die niemand verwacht, want elke stap erbij laadt meer chunks per speler en verhoogt zowel het RAM- als het per-tick-verbruik.

Counter-Strike 2 is de lichte op geheugengebied en de veeleisende op timing. Een schone server zit rond 2.5–3 GB en klimt voorbij 6 GB zodra je plugins, custom workshop-maps en een volle bezetting van 64 slots toevoegt. Hij wordt begrensd door zijn tick-lus en snelheid per core, niet door RAM. Valve omschrijft CS2 als een 64-tick server met een "subtick"-inputlaag die elk schot en elke beweging voorziet van een tijdstempel op het exacte moment waarop het gebeurde, onafhankelijk van de tick, wat nog meer gewicht legt op de server die zijn werk voorspelbaar afrondt; de omschrijving staat op Valves Counter-Strike 2-pagina.

Dan het zware eind. Palworlds officiële vereisten bevelen 16 GB aan, merken op dat 8 GB "ook opstartbaar is, maar de kans op servercrashes door geheugentekort vergroot," en wijzen naar 32 GB voor grotere servers. Operators melden breed dat het geheugengebruik oploopt naarmate de server langer draait, en de standaardoplossing is een geplande herstart om de zoveel uur. ARK: Survival Ascended is nog zwaarder; community-rapporten leggen het servergeheugen op 6–10 GB voordat er iemand verbindt, 16 GB als minimum voor één map, en daarbovenop 12–18 GB voor elke extra map in een cluster. Rust zit daartussenin op 8–16 GB afhankelijk van mapgrootte en bezetting, en is, als Unity-server, net zo klok-gebonden als RAM-gebonden. Valheim is de milde: de eigen documentatie noemt een minimum van 2 GB, al is 4–8 GB het comfortabele cijfer voor een kleine groep op een lang draaiende wereld.

Twee regels dekken ze allemaal. Dimensioneer voor de drukke avond, niet de lege middag; en laat marge over, want een gameserver zonder RAM vertraagt niet netjes, hij crasht of wordt door de kernel midden in de sessie afgeschoten. De sizing-gids werkt de marge-rekensom in algemene termen uit.

Opslag: NVMe, wereldsaves en back-ups

Een gamewereld is een verzameling chunks of regio's die de server continu leest en schrijft terwijl spelers erdoorheen bewegen. Op een draaiende schijf wordt die random I/O het ding dat spelers voelen wanneer een nieuw gebied hapert tijdens het laden. NVMe is het antwoord, en voor een gameserver is dat geen luxe. Chunk-loading, wereldsaves en het wegschrijven van spelersdata landen allemaal op of vlak bij het tick-pad, en de random-read latency van NVMe zit in een andere categorie dan SATA-SSD's, laat staan harde schijven.

Wereldsaves zijn het onderdeel dat mensen onderschatten. Een drukke Minecraft- of Rust-wereld kan uitgroeien tot tientallen gigabytes, en de periodieke save schrijft een groot deel daarvan naar schijf. Op een trage schijf veroorzaakt de save zelf een lagpiek; op NVMe is die snel genoeg klaar om buiten het kritieke pad te blijven. Palworlds eigen documentatie brengt de botte versie van dit punt, met een waarschuwing dat opslag met lage prestaties "opgeslagen data kan beschadigen."

Back-ups staan los van de snelle schijf en zijn niet optioneel. Een wereld is één slechte shutdown verwijderd van verlies, en een gegriefde of teruggedraaide wereld is een restore, geen reparatie. De discipline is simpel te formuleren: frequente snapshots, bewaard op een andere plek dan dezelfde schijf, minstens één keer getest zodat je weet dat de restore ook echt werkt. Back-ups buiten de machine dekken ook het scenario dat de snelle NVMe niet kan dekken: de schijf zelf die het begeeft. RAID 1 over twee NVMe-schijven houdt je draaiende bij het uitvallen van één schijf, maar het is geen back-up, want het spiegelt een verwijdering of corruptie trouw naar beide schijven op hetzelfde moment.

Netwerk en de DDoS-realiteit

Zet een gameserver op een publiek IP en je hebt een doelwit gepubliceerd. Gameservers trekken denial-of-service-aanvallen aan meer dan bijna elke andere workload, om een specifieke reden: spelers kennen het IP, de games draaien over UDP, en een rivaal, een gebande cheater of een ingehuurde booter kan er zonder enige vaardigheid een flood op richten. UDP-floods zijn de gangbare vorm, omdat UDP geen handshake heeft om te rate-limiten en het verkeer makkelijk te spoofen en te versterken is.

Dit is het punt waarop een thuisverbinding of een onbeschermde VPS omvalt. Een consumentenlijn heeft noch de capaciteit om een flood te absorberen, noch upstream scrubbing, dus de aanval verzadigt de verbinding en elke speler valt weg, ongeacht of het serverproces zelf al geraakt wordt. Mitigatie moet gebeuren in het netwerk vóór de server, waar genoeg capaciteit is om het volume op te vangen en filtering om de slechte pakketten te droppen terwijl het echte UDP-verkeer van de game doorgaat. De anatomie van deze aanvallen en de verdediging ertegen wordt behandeld in DDoS-aanvalstypen en bescherming.

Twee praktische kanttekeningen. Game-bewuste filtering telt, omdat generieke DDoS-regels die voor een website werken een game kunnen breken: een UDP-floodfilter moet begrijpen hoe legitiem gameverkeer eruitziet, anders dropt het echte spelers samen met de aanval. En de machine heeft nog steeds hardening op hostniveau nodig, ongeacht upstream-bescherming, want een flood is niet de enige dreiging voor een publieke server; de Linux-hardeningchecklist is de baseline voor het eerste uur.

Een controlepanel draaien op je eigen hardware

Zodra je meer dan een of twee servers draait, wil je een controlepanel in plaats van een stapel tmux-sessies en shellscripts. Drie zijn het kennen waard.

Pterodactyl is de open-source standaard. Het bestaat uit twee delen: het Panel, een PHP-webapplicatie die een database nodig heeft (MySQL 8.0+ of MariaDB 10.6+), een webserver en idealiter Redis; en Wings, de daemon die elke gameserver daadwerkelijk in een Docker-container op de host draait. Die Docker-vereiste is het detail dat je hardware bepaalt. Wings heeft een Linux-host nodig die Docker kan draaien, en Pterodactyls eigen documentatie merkt op dat containergebaseerde VPS-typen, OpenVZ, LXC en Virtuozzo, doorgaans helemaal geen Docker kunnen draaien; KVM is degene die ze garanderen. Op bare metal komt die vraag nooit op, omdat je de kernel zelf bezit.

Pelican is een fork van Pterodactyl, gestart in 2024, die het panel van de MIT-licentie naar AGPLv3 herlicentieerde. De FAQ is er eerlijk over dat het per 2026 nog bètasoftware is, dus behandel het als de snelbewegende optie: kies ervoor als je het nieuwere ontwikkeltempo wilt en met bèta kunt leven, en blijf bij Pterodactyl als je de langer uitgekristalliseerde build wilt. Beide volgen dezelfde panel-plus-daemon-architectuur en dezelfde Docker-vereiste, dus het hardwareverhaal is identiek tussen de twee.

AMP, het Application Management Panel van CubeCoders, is het commerciële alternatief. Het is betaald, draait op zowel Linux als Windows, en ruilt de open-sourcelicentie in voor afwerking en support. Als je liever één ondersteund product koopt dan zelf een stack samenstelt, is dit degene om naar te kijken.

Alle drie maken van één dedicated server een multi-tenant gamehost, wat het eerder genoemde veel-cores-geval concreet maakt. Elke game-instance is zijn eigen single-threaded lus, dus een machine die een panel draait wil zowel hoge klokfrequenties, zodat de tick-lus van elke instance snel blijft, als genoeg cores en RAM om er meerdere tegelijk te draaien zonder dat hun lussen om tijd vechten. De machine dimensioneren komt neer op het optellen van de RAM-cijfers per instance uit de tabel hierboven, plus een paar gigabytes voor het panel en de host, en dan een coreaantal kiezen dat je drukste instances dekt wanneer ze allemaal tegelijk draaien.

Wanneer je geen bare metal nodig hebt

Bare metal is het juiste gereedschap voor een server met volle bezetting op een krap tick-budget. Het is het verkeerde gereedschap voor genoeg praktijkgevallen, en doen alsof dat niet zo is kost je geld.

Een VPS is de betere keuze wanneer:

• Het gaat om een paar vrienden. Drie tot vijf mensen op een vanilla Valheim of een kleine Minecraft-SMP zetten bijna geen belasting op de machine, en de incidentele milliseconde scheduler-jitter is op die schaal onzichtbaar. Valheims minimum van 2 GB draait probleemloos op een kleine VPS.
• Het is één lichte instance. Eén server met lage bezetting voor een game die niet CPU-hongerig is, heeft geen hele fysieke machine voor zichzelf nodig. Je zou betalen voor cores die stilzitten.
• Het is een test- of devmachine. Iets dat je opstart, kapotmaakt en opnieuw uitrolt, wint niets bij dedicated hardware. Goedkoop en wegwerpbaar wint.
• Het is grillig en grotendeels inactief. Een server die het grootste deel van de week leeg is en druk tijdens één raid-avond is precies het patroon waarvoor een gedeeld platform geprijsd is.

Het omslagpunt komt wanneer de server vaak genoeg druk genoeg is dat het tick-budget krap begint te worden; of wanneer de RAM-behoefte het punt overschrijdt waarop dedicated pricing een gelijkwaardige VPS-tier verslaat; of wanneer een publiek game-IP echte DDoS-bescherming ervoor nodig heeft. Onder die grens is een VPS geen compromis, het is het juiste antwoord.

Een snelle beslistabel

Waar elk scenario landt, en de ene factor die het beslist:

Uitrollen op Serverside

Een gameserver beloont de twee dingen waar bare metal goed in is: één proces de hele, snelle CPU geven, en achter een netwerk zitten dat een klap kan opvangen. Een Serverside gameserver-machine draait op ons eigen netwerk (AS55285), met altijd-actieve DDoS-mitigatie vóór de publieke UDP-poort en filteringprofielen afgestemd per gametitel, zodat de flood die een thuis-gehoste server zou vellen de tick-lus nooit bereikt. De configuraties met hoge klokfrequentie, zoals de Ryzen 9950X, zijn gekozen voor precies de single-threaded lus waar dit artikel over gaat, en provisioning duurt minder dan een minuut, dus een verse machine staat live voordat je klaar bent met het plannen van de wereld die erop gaat draaien.

Weeg je hardware breder af, dan behandelen het volledige assortiment dedicated servers en de sizing-gids de rest, en het kiezen van een locatie dicht bij je spelers is een prestatiehefboom op zich; ons datacenter in Amsterdam is het Europese ankerpunt. Zodra de machine van jou is, is de hardeningchecklist het eerste om erop te draaien.

FAQ

Heb ik bare metal nodig voor een gameserver, of is een VPS genoeg?

Dat hangt af van de belasting. Voor een paar vrienden op een vanilla wereld is een VPS genoeg en goedkoper. Bare metal wint zodra de server een vol spelersaantal draait op een krap tick-budget, omdat een gedeelde VPS de scheduler van een hypervisor tussen je tick-lus en de CPU zet, en dat zie je terug als jitter precies op het moment dat een tick op tijd af moet zijn.

Waarom telt klokfrequentie zwaarder dan het aantal cores voor een gameserver?

Omdat een gameserver zijn simulatielus op één thread draait. De wereld stapt in volgorde vooruit, tick voor tick, en dat werk kan niet over cores worden verdeeld. Een snellere core rondt elke tick eerder af, terwijl extra cores door de hoofdlus ongebruikt blijven. Meer cores beginnen pas te helpen zodra je veel instances draait, of een controlepanel dat meerdere servers tegelijk host.

Hoeveel RAM heeft een gameserver nodig?

Dat verschilt sterk per titel. Valheim draait op 2 GB, een Paper Minecraft-server op 3–4 GB voor een kleine groep, Rust op 8–16 GB, en zowel Palworld als ARK: Survival Ascended op 16 GB of meer per instance. Dimensioneer voor een volle server op een drukke avond en laat marge over, want een gameserver zonder RAM crasht in plaats van alleen maar trager te worden.

Kan ik Pterodactyl draaien op een VPS?

Alleen op het juiste type. De Wings-daemon van Pterodactyl draait elke server in een Docker-container, en containergebaseerde VPS-typen zoals OpenVZ en LXC kunnen meestal helemaal geen Docker draaien. Een KVM-VPS werkt wel, en een dedicated server werkt altijd omdat je de kernel zelf bezit. Ben je van plan veel servers achter een panel te hosten, dan is bare metal daar toch al de natuurlijke plek voor.

Krijgen gameservers echt te maken met DDoS-aanvallen?

Ja, meer dan de meeste workloads. Spelers kennen het IP, de games draaien over UDP, en voor een flood is geen vaardigheid nodig. Een thuislijn of een onbeschermde VPS raakt verzadigd en elke speler valt weg. Mitigatie moet in het netwerk vóór de server zitten, met de capaciteit om het volume op te vangen en filtering die gameverkeer van een aanval kan onderscheiden.