Ich wollte wissen, was es kostet, Gameserver-Hoster zu werden. Vier Wochen später hatte ich eine Tabelle und eine Ernüchterung

Es fing mit einer Rechnung an, die ich im Kopf gemacht habe, während ich auf das Rechnungs-PDF meines eigenen Servers geschaut habe. Zwölf Euro im Monat für zehn Slots. Wenn ein Anbieter davon dreihundert Stück laufen hat, sind das 3.600 Euro. Jeden Monat. Für ein „bisschen Blech“ in einem Rechenzentrum, das nachts ohnehin Däumchen dreht. Ich bin Informatiker. Ich hätte es besser wissen müssen.

Gameserver-Hoster werden, das klang für mich nach einem netten Nebenverdienst mit Hardware, auf die ich ohnehin Lust hätte. Was in diesem Artikel steht, ist die vollständige Gegenrechnung dazu: was die Hardware kostet, was Colocation und Strom kosten, wie Overselling technisch funktioniert und wo seine Grenze liegt, ab wann sich das Ganze trägt, was der Support frisst und welcher Stundenlohn am Ende übrig bleibt.

Beantworten lässt sich beides nur, wenn man weiß, was ein Server im Betrieb wirklich kostet. Und das sagt einem niemand. Anbieter werben mit Premium-Hardware und 24/7-Support, Vergleichsseiten wie meine listen Preise, in Foren wird gestritten. Konkrete Zahlen legt niemand offen.

Also habe ich sie selbst zusammengetragen. Konkret gerechnet habe ich an zwei populären Spielen, weil sie technisch gegensätzliche Anforderungen stellen. Minecraft ist für die meisten Hoster das Brot-und-Butter-Geschäft und zugleich der schwierigere Fall, weil es nach starken einzelnen Kernen verlangt statt nach vielen. Valheim ist der Gegenentwurf: feste Zehn-Slot-Pakete, die sich parallel auf einer Maschine stapeln lassen. Und es ist gerade erst interessant geworden, weil das Spiel im September 2026 nach fünfeinhalb Jahren den Early Access verlassen hat, inklusive Crossplay über alle Plattformen. Wer heute kalkuliert, kalkuliert das mit ein.

Was dabei rausgekommen ist, ist ausdrücklich kein Businessplan. Finanzierung, Gemeinkosten und Abschreibung fehlen darin. Es ist eine Kalkulation, die ich zu Ende gerechnet habe, weil ich wissen wollte, wo die Zahl kippt. Und sie kippt früher, als ich dachte.

Hier sind meine Zahlen, alle offengelegt. Die komplette Kalkulation liegt als Tabelle offen, in der du jede Annahme selbst verändern kannst. Als Excel-Datei zum Herunterladen, der Link steht unten.

Warum ein normaler Cloud-Server für Gaming die falsche Maschine ist

Der erste Denkfehler, den ich hatte und den in den Foren gefühlt jeder Neueinsteiger macht: Man kauft die CPU mit den meisten Kernen fürs Geld. Für Webhosting, Datenbanken oder Container-Cloud ist das richtig. Für Gameserver ist es der sicherste Weg, unzufriedene Kunden zu produzieren.

Der Grund liegt in der Architektur der Spiele. Minecraft Java berechnet seine Spiellogik, also die berühmten zwanzig Ticks pro Sekunde, im Kern nach wie vor auf einem einzigen Thread. Chunk-Generierung und I/O sind inzwischen parallelisiert, und Paper hat mit Folia einen regionalisierten Multithreading-Ansatz gebaut, bei dem verschiedene Weltregionen auf verschiedenen Threads laufen. Aber Folia lohnt sich erst bei großen, weit verteilten Spielerzahlen, bricht Kompatibilität mit vielen Plugins und ist für den typischen 20-Mann-Freundesserver schlicht nicht relevant. In der Praxis heißt das: Wenn deine CPU bei 2,2 Gigahertz herumdümpelt, fällt die Tickrate unter Last, und der Kunde spürt genau das Gummiband-Gefühl, für das er dich anschließend auf Trustpilot bewertet.

Valheim ist der Gegenentwurf: Unity-Engine, feste Zehn-Slot-Pakete, Kommunikation über den Steam-Networking-Stack. Hier zählt keine Single-Core-Spitzenleistung, sondern Dichte: möglichst viele kleine, isolierte Welten pro Höheneinheit im Rack.

Der Cluster, den ich kalkuliert habe

Das F im 9474F steht für frequency-optimized. AMD verkauft die Reihe genau für Workloads, die Takt statt Kerne brauchen, und Minecraft-Hosting ist das Lehrbuchbeispiel dafür. Die 256 Megabyte L3-Cache sind dabei nicht nur eine schöne Zahl auf dem Datenblatt: Entity-Berechnungen sind extrem cache-sensitiv, und ein Cache-Miss kostet dich mitten im Tick genau die Millisekunden, die du nicht hast.

Ein Detail, über das ich in den Foren mehrfach gestolpert bin und das ich fast falsch gemacht hätte: Genoa hat zwölf Speicherkanäle. Die müssen alle gleich bestückt sein, sonst verlierst du Bandbreite, und zwar nicht ein bisschen. 384 Gigabyte bedeuten also zwölf Riegel à 32 Gigabyte, nicht acht à 48. Voll bestückt liegen 460,8 Gigabyte pro Sekunde an, und die brauchst du, wenn hundert JVMs gleichzeitig Welt-Chunks laden. Wer hier 512 Gigabyte einplant, hat schon beim Einkauf einen Fehler gemacht: 512 lässt sich nicht sinnvoll auf zwölf Kanäle verteilen.

Storage sind pro Knoten zwei Enterprise-NVMe im PCIe-Gen5-U.2 oder U3-Format mit Power Loss Protection, gespiegelt im ZFS-Pool. ZFS deshalb, weil ich einen Teil des RAM als ARC nutzen kann. Häufig gelesene Weltdaten liegen dann im Speicher statt auf der SSD. Netzwerk sind zwei mal zehn Gigabit im LACP-Bonding, Netzteile redundant auf getrennten Stromphasen.

Was die Hardware wirklich kostet

Hier war meine erste Zahl deutlich zu schön. Ich hatte im Kopf, dass so ein Cluster für 16.000 oder 17.000 Euro machbar sein müsste. Dann habe ich angefangen, Positionen zusammenzusuchen, und die Rechnung sah anders aus. Und dann noch einmal anders, als ich die Preise kurz vor der Veröffentlichung ein letztes Mal geprüft habe.

Günstigstes gelistetes Angebot auf Geizhals, Tray- und Bulk-Ware, auf netto umgerechnet, Stand 25. Oktober 2026.

Die Position, die alles verschoben hat, ist der Arbeitsspeicher. In meiner ersten Fassung stand ein 32-Gigabyte-Riegel mit 150 Euro drin, das war der Preis vom Herbst 2025. Heute kostet derselbe Riegel rund 990 Euro netto, und 36 Stück sind mit über 35.000 Euro mehr als die Hälfte der gesamten Investition. Die SSDs haben sich im selben Zeitraum ungefähr verdreifacht. Der Grund ist derselbe: KI-Rechenzentren kaufen Speicher in Mengen, gegen die ein kleiner Hoster keine Verhandlungsposition hat. Mit einer Entspannung rechnen Marktbeobachter frühestens 2027.

Der Punkt, den ich in den Foren immer wieder gelesen habe und der mir vorher nicht klar war: Der EPYC 9654 hatte mal einen Listenpreis von über 8.000 Dollar. Heute bekommst du ihn als Tray-CPU für unter 3.000 Euro.

Genoa ist inzwischen die Generation davor, und bei den Prozessoren ist High-End-Gamehosting dadurch für kleine Anbieter bezahlbar geworden. Nur hilft das wenig, solange der Speicher daneben ein Vielfaches kostet. Wer hier auf die aktuellste Plattform schielt, verbrennt Geld für Leistung, die kein Minecraft-Server je abruft.

Weiterer Punkt, der leicht untergeht: 64.000 Euro sind Startkapital, das erstmal weg ist. Bei gemieteten Rootservern hättest du diese Zahl nicht, dafür dauerhaft deutlich höhere Fixkosten pro Node.

Ich habe trotzdem den Kaufweg gerechnet, und zwar nicht, weil er der sportlichere ist, sondern weil er das realistischere Szenario abbildet. Zwei Gründe. Erstens liegt die Rentabilitätsgrenze beim Kauf früher: Weil die Hardware nicht Monat für Monat als Mietposten in den Fixkosten steht, brauchst du weniger Kunden, um schwarze Zahlen zu schreiben. Der Preis dafür ist, dass die Abschreibung in meiner monatlichen Rechnung nicht auftaucht. Wer buchhalterisch sauber rechnet, muss sie ansetzen, und dann sieht das Monatsergebnis wieder blasser aus.

Zweitens verlangt der Kaufweg die Fertigungstiefe, die einen Hoster überhaupt erst von einem Reseller unterscheidet. Du machst Beschaffung, Bestückung, Rackmontage, Ersatzteilhaltung und Remote Hands selbst. Genau daran hängt aber die Marge, mit der die etablierten Anbieter arbeiten. Wer stattdessen Rootserver mietet und weiterverkauft, kommt mit ein paar hundert Euro Startkapital rein, gibt aber einen guten Teil seiner Marge an den Vermieter ab und kann bei Hardwareproblemen nur Tickets schreiben statt selbst zu handeln.

Muss es wirklich eigene Hardware sein?

Nein, und für die meisten wäre es die falsche Entscheidung. Es gibt vier Wege in dieses Geschäft, und sie unterscheiden sich weniger in der Technik als im Risiko.

Die ersten beiden Zeilen habe ich bewusst nicht durchgerechnet, weil sie eine andere Frage beantworten. Wer einen Rootserver mietet, hat kein Kapital gebunden, dafür steht die Hardware jeden Monat als Fixkosten in der Rechnung, und ein guter Teil der Marge gehört dem Vermieter. Der Break-Even kommt dort früher, die Decke aber auch.

Wenn du ernsthaft überlegst, einzusteigen, würde ich in dieser Reihenfolge vorgehen und nicht in umgekehrter. Die 64.000 Euro sind der letzte Schritt, nicht der erste.

Das Software-Fundament, und warum die Panel-Frage 2026 anders aussieht als noch vor zwei Jahren

Auf dem Blech läuft ein schlankes Debian oder Ubuntu LTS, darauf Docker, und darauf startet jeder Kundenserver in einem eigenen Container. Das ist Industriestandard, und es hat einen sehr praktischen Grund: Wenn ein Kunde ein kaputtes Plugin installiert, darf er nicht den halben Node mitreißen.

Interessant wird es beim Container-Betriebssystem. Ein vollwertiges Linux pro Instanz wäre bei 130 Containern pro Node absurd. Stattdessen laufen extrem abgespeckte Alpine- oder Debian-Slim-Images unter hundert Megabyte. Kein SSH, kein Cron, kein Syslog, nur die Laufzeitumgebung, die das Spiel braucht: ein OpenJDK für Minecraft, SteamCMD für Valheim. Im Standby verbraucht so ein Container praktisch nichts, und die zugewiesenen Ressourcen landen vollständig beim Spielprozess.

Pterodactyl, Pelican und eine Lizenzfrage, die anders ausgeht als gedacht

Pterodactyl ist seit Jahren die Standardantwort auf diese Frage: Panel plus Wings-Daemon in Go, Docker darunter, und viele Anbieter setzen darauf auf. Das Projekt steht unter der MIT-Lizenz und wird aktiv weiterentwickelt. Zwischen Juni und August 2026 kamen die Versionen 1.13, 1.14 und 1.15 heraus, seit Mitte Oktober läuft eine offene Beta von Version 2.0.

Pelican ist die jüngere Alternative aus demselben Umfeld. Das Projekt beschreibt sich selbst als moderne Alternative im Pterodactyl-Ökosystem, arbeitet ebenfalls mit einem Wings-Daemon und hat nach einer langen Beta-Phase im Oktober 2026 die ersten Release Candidates für Version 1.0 veröffentlicht.

Der Unterschied, der für einen kommerziellen Hoster zählt, ist die Lizenz, und er läuft anders, als man vermuten würde. Pterodactyl steht unter MIT: Du darfst den Code anpassen und dein eigenes Interface darauf bauen, ohne deine Änderungen offenlegen zu müssen. Pelicans Panel steht unter AGPLv3. Wer ein öffentlich erreichbares Panel im Kern verändert, muss diese Änderungen offenlegen. Der Daemon steht bei Pelican unter MIT, die Pflicht betrifft also das Panel selbst. Für jeden, der sich ein eigenes Interface als Alleinstellungsmerkmal bauen will, ist das die wichtigste Zeile im ganzen Vergleich.

Beim Thema Sicherheit lohnt es sich, genau hinzusehen, statt einzelne Lücken gegeneinander aufzurechnen. Pterodactyl hatte im Juni 2025 eine kritische Lücke, über die Angreifer ohne Anmeldung Code auf dem Server ausführen konnten; behoben ist sie seit Version 1.11.11. Pelican hat in seiner Beta-Phase ebenfalls eine Reihe von Sicherheitshinweisen veröffentlicht, allein im Juli und September 2026 sieben, mehrere davon als hoch eingestuft. Keins von beidem macht ein Panel unbrauchbar. Es zeigt nur, dass das Panel die Software mit der größten Angriffsfläche auf deinem Node ist: öffentlich erreichbar und mit Zugriff auf jeden Kundenserver. Wer nicht innerhalb eines Tages nach einem kritischen Advisory patcht, hat ein Problem, egal welches Panel er betreibt.

Die praktische Konsequenz für meine Kalkulation: An der Rechnung ändert die Wahl nichts. Beide Panels sind kostenlos und folgen demselben Prinzip aus Panel, Daemon und Docker. Für einen kommerziellen Hoster, der ein eigenes Interface bauen will, spricht die Lizenz klar für Pterodactyl, zumal die stabile 1.x-Reihe gepflegt wird und 2.0 in Sicht ist. Pelican bleibt eine ernsthafte Alternative, wenn du das Panel nicht im Kern umbauen willst — dann spielt die AGPL keine Rolle. Nach der langen Beta allerdings mit dem Vorbehalt, dass Version 1.0 erst noch zeigen muss, wie sie sich im Dauerbetrieb schlägt.

Kosten für das Panel: null. Beide sind frei, ohne Lizenzgebühren und ohne Nutzungslimits. Was Geld kostet, sind Billing und Automation. WHMCS liegt je nach Lizenz bei rund 25 Euro im Monat, dazu kommen deutsche Rechtsmodule und Panel-Addons.

Kernel-Tuning ist kein Nice-to-have

Ein Standard-Linux ist für Gameserver falsch konfiguriert. Gameserver kommunizieren über UDP, und der Default-Netzwerk-Stack ist für TCP-Webtraffic ausgelegt.

Die Stellschrauben, die in jeder Diskussion auftauchen: net.core.rmem_max und net.core.wmem_max hochsetzen, damit dir bei Traffic-Spitzen keine Pakete im Socket-Buffer verloren gehen. nf_conntrack_max erhöhen, weil die Connection-Tracking-Tabelle bei hunderten parallelen UDP-Sessions sonst überläuft und der Node ab dann stumm Pakete verwirft, ohne dass irgendwo eine Fehlermeldung auftaucht. Und Cgroups v2 sauber konfigurieren, damit ein durchdrehender Container über das Hard-Capping abgefangen wird, statt seine Nachbarn mit in den Abgrund zu ziehen.

Overselling: der Teil, über den in Foren geflüstert und in Werbetexten geschwiegen wird

Jetzt kommt der Punkt, an dem meine Kalkulation überhaupt erst funktioniert, und an dem ich lange gebraucht habe, um ihn ohne moralischen Unterton zu betrachten.

Ressourcen eins zu eins zu vergeben, funktioniert im Consumer-Hosting nicht. Technisch ließe sich zwar beides fest zuteilen: CPU-Kerne lassen sich einem Container exklusiv zuweisen, RAM ebenso mit harten Limits. Nur wäre das wirtschaftlich unmöglich, weil die zugeteilten Ressourcen die meiste Zeit brachliegen. Die eigentliche Frage ist deshalb nicht, ob überbucht wird, sondern welche Ressource geteilt wird, wie viel Reserve dabei bleibt und was dem Kunden tatsächlich zugesichert ist. Wenn du 384 Gigabyte RAM hast und Vier-Gigabyte-Pakete verkaufst, wären das 88 Server. Zu dem Preis, den der Markt zahlt, wärst du damit sofort insolvent. Overselling ist im Consumer-Hosting kein Betrug, sondern die Betriebsgrundlage. Die Frage ist nur, wie weit man geht.

Beim Arbeitsspeicher funktioniert das, weil Gamer asynchron spielen. Ein Valheim-Server im Leerlauf belegt ungefähr anderthalb Gigabyte. Ein Betreiber hat mir dazu einen gemessenen Median von 1,4 bis 1,6 Gigabyte genannt, mit einzelnen Ausreißern bis 2,4 — die Weltgröße schlägt dabei weniger durch, als ich erwartet hätte. Erst wenn Spieler auf dem Server sind, steigt der Bedarf auf bis zu vier Gigabyte. Und dass alle Kunden gleichzeitig online sind, kommt praktisch nie vor. Genau diese Lücke zwischen Leerlauf und Vollbetrieb ist das, was du überbuchst.

Bei der Rechenzeit trägt dasselbe Argument nicht, und das war die unangenehmste Korrektur an meiner Rechnung. Ein leerer Valheim-Server kostet fast so viel CPU wie ein voller. Warum das so ist und was es für die Belegung eines Knotens bedeutet, steht gleich im nächsten Abschnitt.

Alle Verbrauchswerte hier sind Modellannahmen für diese Kalkulation, keine garantierten Größen. Der reale Bedarf schwankt mit Spielerzahl, Mods, Serverlaufzeit und Serverversion.

Meine Annahme für den Peak: dreißig Prozent der laufenden Server haben gleichzeitig Spieler. Bei Minecraft ist das ein Abendwert, bei Valheim gilt er rund um die Uhr. Das ist eine Schätzung aus Foren-Erfahrungsberichten, keine Branchenstatistik, und es ist die mit Abstand wackeligste Zahl im ganzen Modell. Was passiert, wenn sie falsch ist, rechne ich gleich im Anschluss durch.

Node 2 im Valheim-Betrieb, durchgerechnet

Von 384 Gigabyte gehen etwa 32 für Host-System und ZFS-ARC ab. Bleiben 352 Gigabyte nutzbar.

Auf der CPU-Seite dachte ich, es sei entspannter: 130 Server à zwei vCPU wären 260 Threads auf 192, aber aktiv ist davon nur ein Teil, und wer im Leerlauf nichts braucht, gibt seine Zyklen frei.

Bei Minecraft stimmt das. Der Server tickt nur geladene Chunks, und Chunks laden um Spieler herum. Steht niemand drauf, bleibt außer den Spawn-Chunks fast nichts geladen.

Bei Valheim stimmt es nicht, und der Grund hat mich überrascht. Der Valheim-Server simuliert die Welt nämlich gar nicht selbst. In der Standardversion besitzt der Client, der eine Zone zuerst betritt, diese Zone und rechnet Mobs, Physik und Bauwerke auf seinem eigenen Rechner. Es gibt auch eigens Mods, die diese Aufgabe an den Server zurückgeben würden. Offenbar schreitet auf einem leeren Server nicht einmal die Spielzeit voran.

Trotzdem zieht ein leerer Valheim-Server dauerhaft einen erheblichen Teil eines Kerns. Das ist seit Jahren dokumentiert: Nutzer berichten 35 bis 50 Prozent Last auf einem Kern bei leerem Server, und der Maintainer des verbreiteten Docker-Images verweist darauf, dass es am Valheim-Server selbst liegt. Ein Betreiber hat mir auf Serverhardware rund 0,8 Threads pro leerer Instanz gemessen, gegenüber etwa 1,0 bei einer mit Spielern. Mehr als einen Thread kann eine Instanz ohnehin nicht nutzen, weil der Mainloop praktisch single-threaded ist. Die Last entsteht also nicht durch die Welt, sondern durch den Serverprozess — und das erklärt auch, warum ein voller Server kaum mehr kostet als ein leerer.

Für die Belegung heißt das: Nicht die Spielerzahl entscheidet, sondern wie viele Instanzen eingeschaltet sind. Rechne ich mit diesen Werten, komme ich für 130 Valheim-Server auf gut 110 Threads dauerhaft statt auf 78 im Peak. Fairerweise gilt das nicht nur für Valheim: Rechnet man auch den Minecraft-Knoten gegen seine 48 physischen Kerne statt gegen 96 Threads, liegt er bei 113 Prozent. Nur ist die zugeteilte Obergrenze dort eine, die wirklich nur unter Last erreicht wird, und sie liegt nicht rund um die Uhr an. Und die ehrliche Bezugsgröße sind dabei nicht die 192 SMT-Threads, sondern die 96 physischen Kerne. Zwei single-threaded Tick-Loops auf demselben Kern teilen sich dieselben Ausführungseinheiten, und das schlägt auf die Tickzeit durch, also auf genau das, was der Spieler als Ruckeln merkt.

Damit gehen 130 Valheim-Server pro Knoten rechnerisch nicht sauber auf. Ich lasse die Zahl trotzdem stehen, aus zwei Gründen: Die Messung stammt von fremder Hardware mit unbekanntem Takt, und ein einzelner Datenpunkt sollte nicht die ganze Rechnung umwerfen. Es ist aber die unsicherste Annahme in diesem Artikel. Im Sheet steht der CPU-Bedarf pro Instanz deshalb als eigene Eingabezelle, mit 0,8 für eine leere und 1,0 für eine belegte Valheim-Instanz. Wer eigene Messwerte hat, trägt sie dort ein und sieht sofort, was mit der Knotenbelegung passiert. Rechnerisch trägt der Valheim-Knoten mit diesen Werten rund 112 statt 130 verkaufte Server, der Minecraft-Knoten 80 statt 90. Wer lieber damit arbeitet, ändert im Sheet zwei Zellen und bekommt die gesamte Rechnung neu.

Beim Arbeitsspeicher sieht die Rechnung für Minecraft auf Node 1 ähnlich aus, mit 90 verkauften Sechs-Gigabyte-Servern und 288 Gigabyte Peak-Verbrauch. Macht in Summe: 90 Minecraft- plus 260 Valheim-Server, also 350 Kundenserver auf drei Maschinen.

Der Trick, der Minecraft-Overselling erst möglich macht

Hier kommt ein Detail, das ich bemerkenswert finde, weil es die Interessen von Hoster und Kunde direkt gegeneinanderstellt.

Aikars Flags, die De-facto-Standardkonfiguration für Minecraft-Server, empfehlen -Xms und -Xmx auf denselben Wert zu setzen. Die JVM reserviert dann sofort den vollen Heap und gibt ihn nie wieder her. Für den einzelnen Server ist das gut: stabiles Verhalten, weniger GC-Ärger. Für den Hoster ist es eine Katastrophe. Wenn jeder Sechs-Gigabyte-Kunde tatsächlich dauerhaft sechs Gigabyte belegt, ist Overselling unmöglich, und aus 90 verkauften Servern würden rechnerisch nur noch 58. Wie viel RAM ein Server tatsächlich braucht, hängt stark von Modpack und Spielerzahl ab. Das habe ich hier im Detail aufgeschlüsselt.

Deshalb setzen viele Anbieter -Xms bewusst niedrig und verlassen sich darauf, dass der Garbage Collector nicht mehr benötigten Speicher ans Betriebssystem zurückgibt. ZGC und Shenandoah können das gut, G1 mit passenden Flags auch. Praktischer Nebeneffekt für dich als Kunde: Wenn dein Anbieter dich -Xms nicht selbst setzen lässt, weißt du jetzt, warum.

Apropos Garbage Collector: In dem Zusammenhang liest man oft, man müsse ab Java 21 zwingend Generational ZGC nehmen. Das halte ich für zu pauschal. G1 mit Aikars Flags ist bei Heaps zwischen vier und zwölf Gigabyte weiterhin die solidere Wahl, weil ZGC seine Sub-Millisekunden-Pausen mit spürbar weniger Durchsatz erkauft. Interessant wird ZGC oberhalb von etwa zwölf bis sechzehn Gigabyte, also bei großen Modpack-Servern. Darunter löst es ein Problem, das du gar nicht hast.

Und noch ein Punkt, den ich in Support-Threads immer wieder gesehen habe, ohne dass jemand die Ursache benennt: Docker setzt ein hartes Memory-Limit. Überschreitet der Container es, greift der OOM-Killer und beendet den Prozess. Aus Kundensicht sieht das aus wie ein zufälliger Absturz ohne Fehlermeldung im Log. Wenn dein Server reproduzierbar beim Laden großer Modpacks stirbt, ist das meistens genau das.

Was passiert, wenn ich mich bei der Concurrency irre

Das habe ich mir zum Schluss angesehen, und das Ergebnis hat meine Vorstellung davon, was Overselling eigentlich ist, umgebaut.

Ich hatte erwartet: höhere Concurrency, weniger Gewinn. Falsch. Wenn ich in der Tabelle nur die Peak-Annahme hochdrehe und sonst nichts ändere, bleibt das Monatsergebnis auf den Cent identisch. Es ändert sich einzig, wie viel Luft auf der Maschine bleibt. Die folgenden Werte sind für Node 1 gerechnet, also den Minecraft-Knoten. Auf den beiden Valheim-Knoten liegen sie sehr ähnlich, zwischen 83 und 97 Prozent.

Zehn Gigabyte Reserve auf einer Maschine mit 352 nutzbaren Gigabyte. Ein Kunde lädt ein großes Modpack, und der OOM-Killer fängt an zu arbeiten. Genau das ist der Mechanismus hinter dem, was Spieler als billigen Hoster mit schlechten TPS erleben. Es ist nicht so, dass jemand an der Hardware gespart hätte. Er hat an der Reserve gespart, und das sieht man auf keinem Datenblatt.

Zur Gewinnfrage wird die Concurrency erst, wenn man ehrlich auf sie reagiert. Wer bei vierzig Prozent dieselben 83 Prozent Auslastung halten will, muss weniger verkaufen: 81 statt 90 Minecraft-Server, 117 statt 130 Valheim-Server pro Knoten. Aus 350 Kundenservern werden 315.

Zehn Prozentpunkte Fehleinschätzung kosten achtzehn Prozent Marge und neun Monate Amortisation, wenn du sie einpreist. Preist du sie nicht ein, kosten sie stattdessen deine Kunden 36 Gigabyte Puffer. Die dritte Spalte rechnet die gemessenen CPU-Werte konsequent durch: 112 Valheim-Server pro Knoten und 80 Minecraft-Server, zusammen 304. Damit liegen die physischen Kerne bei genau hundert Prozent, also ohne jede Reserve. Das Monatsergebnis fällt auf rund 1.506 Euro, das Kapital ist erst in Monat 66 zurück. Zur Hauptrechnung habe ich diese Variante nicht gemacht, weil der CPU-Wert die unsicherste Zahl im Modell ist. Wer mit ihm rechnen will, findet hier die Konsequenz.

Der DDoS-Schutz, den du nicht selbst bauen kannst

Du kannst die schnellste CPU der Welt haben. Wenn jemand ein Amplification-Botnetz mit 200 Gigabit pro Sekunde auf deinen Port richtet, ist der Node offline, bevor du die Konsole offen hast.

Das ist die eine Position in meiner Kalkulation, bei der Selbermachen keine Option ist. Filterung muss upstream passieren, bevor der Traffic deinen Uplink erreicht.

Das gilt allerdings für meine Größenordnung, nicht grundsätzlich. Wer ein eigenes Netz mit eigenen Uplinks betreibt, kann Filterhardware selbst betreiben. Appliances wie Corero SmartWall stehen inline am eigenen Netzrand und waschen den Verkehr, bevor er die Nodes erreicht. Aus der monatlichen Transitrechnung wird dann eine Anschaffung plus Wartung. Nur verschiebt das die Grenze, es hebt sie nicht auf: Übersteigt ein Angriff die Kapazität deiner Uplinks, ist die Leitung voll, bevor das Gerät entscheiden darf. Deshalb fahren auch Anbieter mit eigener Hardware mehrstufig, mit Upstream-Mitigation davor. Für drei Knoten an zweimal zehn Gigabit ist der Eigenbau keine Option. Ab eigenem Netz und mehreren Carriern wird er zur Frage der Kalkulation.

Und hier wird es spezifisch: Klassische Web-DDoS-Filter helfen nur begrenzt. Der kostenlose HTTP-Proxy von Cloudflare bringt dir für einen Minecraft-Port genau nichts, weil er ausschließlich HTTP und HTTPS weiterleitet. Minecraft Java spricht rohes TCP auf Port 25565, Bedrock und viele andere Spiele UDP und beides nimmt der kostenlose Proxy gar nicht erst an. Cloudflare kann UDP durchaus filtern, über Spectrum und Magic Transit, aber das sind Enterprise-Produkte mit entsprechenden Preisen. Der Satz „Cloudflare funktioniert für Gameserver nicht“ ist verkürzt. Richtig ist: Das, was du kostenlos bekommst, funktioniert nicht.

Zur Filterebene gehört allerdings eine Differenzierung, auf die mich ein Betreiber gebracht hat. Eine einfache Layer-4-Filterung kann tatsächlich nicht erkennen, ob ein formal gültiges UDP-Paket von einem Spieler oder aus einem Angriff stammt. Moderne L4-Mitigation schaut aber nicht nur auf Port und Paketgröße, sondern auch auf Paketraten, Verbindungszustände, Verkehrsmuster und Abweichungen vom normalen Quellverhalten. Damit lassen sich volumetrische und deutlich auffällige Angriffe bereits weitgehend abfangen. Eng wird es erst, wenn ein Angriff den legitimen Spielverkehr sehr genau nachahmt. Dann braucht es protokoll- oder spielspezifische Mechanismen.

Was in der Gameserver-Szene tatsächlich eingesetzt wird, sind spezialisierte gefilterte Transits. Der bekannteste Name im deutschsprachigen Raum ist aurologic, bis zur Umfirmierung 2023 als combahton bekannt, mit der eigenentwickelten Filter-Appliance flowShield. Dazu kommen Anbieter wie Path.net oder OVH mit seinem VAC-System. Für genau diesen Fall läuft der Traffic dauerhaft durch Scrubbing-Hardware, die nach Anbieterangaben per Deep Packet Inspection bis auf die Anwendungsebene prüft, ob sich ein Client protokollkonform am Minecraft- oder Steam-Handshake anmeldet. Pakete mit strukturellen Anomalien fliegen an der Edge raus, bevor sie dein Betriebssystem sehen. Der Ping der echten Spieler bleibt unberührt.

In meiner Rechnung stehen dafür 400 Euro im Monat. Das ist der Posten, bei dem ich mir am unsichersten bin, weil die Preise stark vom zugesicherten Volumen abhängen. Nach oben ist da viel Luft.

Die Betriebskosten, Position für Position

Was hier nicht drinsteht: dein eigenes Gehalt. Und Zahlungsgebühren, die rechne ich gleich separat, weil sie mit der Kundenzahl mitwachsen.

Zum Strom, weil das die Frage ist, die ich mir selbst falsch beantwortet hatte: Nein, bei Colocation ist der Strom nicht im Stellplatzpreis enthalten. Jedenfalls nicht in der Menge, die du brauchst. Was du im Grundpreis bekommst, ist eine symbolische Pauschale. Typische Angebote nennen 50 Voltampere oder 85 Watt pro Höheneinheit. Ein EPYC-Knoten zieht ungefähr das Sechs- bis Zehnfache davon. Alles darüber wird nach gemessenem Verbrauch abgerechnet, und die Preise liegen aktuell zwischen etwa 0,33 und 0,45 Euro pro Kilowattstunde, je nach Rechenzentrum und Vertrag.

Ein EPYC 9654 hat 360 Watt TDP, läuft im Gameserver-Betrieb aber selten am Anschlag. Ich rechne mit rund 500 Watt pro Knoten inklusive RAM, NVMe und Lüftern, also etwa 1,5 Kilowatt im Schnitt für den Cluster. Bei 0,35 Euro netto pro Kilowattstunde sind das 383 Euro im Monat.

Der Strom ist damit nach dem DDoS-Schutz der zweitgrößte technische Kostenblock, und er ist der Grund, warum du bei jedem Colocation-Angebot zuerst nachfragen solltest, wie abgerechnet wird. Wer glaubt, deutsche Hoster seien einfach gierig: Ein Anbieter in Finnland oder Frankreich zahlt hier deutlich weniger.

Die Frage, wegen der ich das Ganze angefangen habe

Am Anfang stand diese Rechnung im Kopf: dreihundert Server mal zwölf Euro, macht 3.600 Euro im Monat. Jetzt weiß ich, was die Hardware kostet, was das Rechenzentrum nimmt, wie viele Kunden auf einen Knoten passen und wie viel Reserve man ihnen lassen muss. Alles, was noch fehlt, ist eine Subtraktion.

Und die erste Korrektur passiert schon bei den zwölf Euro. Der Kunde zahlt sie, aber bei dir kommen sie nicht an: Zehn-Slot-Valheim für 12 Euro brutto sind netto 10,08 Euro, Sechs-Gigabyte-Minecraft für 15 Euro brutto sind 12,61 Euro. Neunzehn Prozent gehören dem Finanzamt, bevor du irgendetwas bezahlt hast. Aus meinen 3.600 Euro sind damit, noch vor dem ersten Kostenpunkt, gut 3.000 geworden.

Bleibt die Frage, was von den 3.000 übrig bleibt. Hier ist die vollständige Rechnung.

Und jetzt die Zahl, die mich am meisten überrascht hat.

Bei Vollauslastung wäre der Hardware-Einsatz nach knapp 33 Monaten aus dem laufenden Überschuss zurückverdient. Buchhalterisch ist das keine Amortisation, weil die Abschreibung in meiner Rechnung nicht auftaucht, aber es ist der Moment, in dem das Geld wieder auf dem Konto ist.

Nur ist niemand am ersten Tag voll ausgelastet. Nimm an, du brauchst zwei Jahre, um den Cluster zu füllen, und zwar linear. Dann bist du in den ersten zehn Monaten im Minus, weil du unter der Break-Even-Marke liegst. Über die vollen 24 Monate erwirtschaftest du kumuliert rund 6.600 Euro. Danach dauert es bei voller Auslastung nochmal rund dreißig Monate, bis das Startkapital zurückgezahlt ist.

Macht 54 Monate. Viereinhalb Jahre, bis das eingesetzte Kapital wieder bei dir ist.

Und das ist der optimistische Fall. Er unterstellt, dass du in zwei Jahren aus dem Nichts 350 zahlende Kunden gewinnst, in einem Markt, in dem GPORTAL, ZAP-Hosting und Nitrado seit über einem Jahrzehnt sitzen und Marketingbudgets haben, gegen die deine 250 Euro im Monat ein Trinkgeld sind.

Die Support-Falle, oder: Warum das keine passive Einnahmequelle ist

In den Hosting-Foren taucht eine Faustregel immer wieder auf: Zwischen zehn und fünfzehn Prozent deiner Kunden eröffnen pro Monat mindestens ein Ticket. Belastbar belegt habe ich das nirgends gefunden, aber es deckt sich mit dem, was Betreiber selbst berichten.

Bei 350 Kunden sind das 35 bis 53 Tickets im Monat.

Gaming-Kunden sind dabei eine besondere Spezies, und ich sage das als einer von ihnen. Wenn der Server am Freitag um 20 Uhr wegen eines kaputten Community-Mods stirbt, ist Freitag um 20 Uhr die Zeit, in der geholfen werden muss. Wer bis Samstagmittag auf eine Antwort wartet, kündigt und hinterlässt vorher noch eine Bewertung. Wie schnell das eskaliert, wenn ein Anbieter das unterschätzt, hat die ARK-Community bei Nitrado vorgeführt.

Rechne ich dreißig Minuten pro Ticket, sind das 18 bis 26 Stunden nur Support. Dazu kommen Patching und Wartung, Buchhaltung und Rechnungsläufe, Monitoring-Alarme und Marketing. Ich lande bei etwa 55 bis 60 Stunden im Monat.

1.964 Euro geteilt durch 57,75 Stunden sind 34 Euro pro Stunde vor Steuern. Als Selbstständiger, ohne bezahlten Urlaub, ohne Krankheitsausfall, ohne Altersvorsorge. Was davon netto übrig bleibt, hängt an Rechtsform, Hebesatz und persönlicher Situation, aber es wird deutlich weniger. Ich bin Informatiker. Meine Opportunitätskosten liegen um ein Vielfaches höher. Das ist an dieser Stelle keine Angeberei, sondern der eigentliche Punkt: Für jemanden mit meinem Hintergrund ist das kein Geschäftsmodell, sondern ein teuer bezahltes Hobby mit Rufbereitschaft.

Und die naheliegende Lösung funktioniert nicht. Wenn du den Support abgibst, kostet dich schon ein Minijobber an der Verdienstgrenze von 603 Euro inklusive Pauschalabgaben rund 790 Euro im Monat. Das sind rund 40 Prozent deines Gewinns, für jemanden, der etwa 43 Stunden im Monat da ist — weniger als die Arbeit, die du abgeben willst.

Die einzige Antwort, die in den Foren wirklich funktioniert hat, ist unbequem: Support wegautomatisieren, bevor er entsteht. Ein-Klick-Modinstaller mit direkter Anbindung an CurseForge und Modrinth, damit niemand FTP anfassen muss. Automatische, versionierte Backups mit Ein-Klick-Rollback, damit der Freitagabend-Crash ein Zwei-Minuten-Problem ist statt eines Tickets. Verständliche Konfigurations-Oberflächen statt roher Config-Dateien. Wie weit die Anbieter dabei sind, habe ich mir in den einzelnen Hoster-Reviews angesehen. Nur ist das kein Schalter, den man umlegt. Diese Automatisierung muss entwickelt, getestet und laufend gepflegt werden, und zwar genau in der Phase, in der ohnehin alles gleichzeitig ansteht. Ein neuer Anbieter automatisiert den Support nicht weg, er investiert erst einmal viel Zeit, bevor sich die Arbeit überhaupt auszahlt. Geprüfte Servervorlagen, verständliche Einstellungen und verlässliche Backups entstehen nicht nebenbei.

Was die Automatisierung aber nicht wegnimmt, ist der Rest. Ein Modinstaller löst das Problem, das er löst. Wenn ein Server trotzdem abstürzt und jemand nicht weiterweiß, will dieser Kunde keinen Hilfeartikel, sondern eine Antwort von einem Menschen, der sich sein Problem ansieht. Das ist auch nicht unvernünftig, denn genau dafür zahlt er.

Ein gutes Panel senkt die Ticketzahl deutlich, aber es macht sie nicht zu null. Und der Teil, der übrig bleibt, ist ausgerechnet der schwierige: die Fälle, für die es keine Vorlage gibt. Die sind zeitintensiver als der Durchschnitt und sie treffen dich zu den ungünstigsten Zeiten. Personal ist deshalb keine Frage des Ob, sondern des Wann. Sobald du ernsthaft wächst, steht es in der Rechnung.

Das ist ein Grund, warum die etablierten Anbieter so viel in ihre Webinterfaces investieren. Nicht, weil es hübsch aussieht, sondern weil jedes verhinderte Ticket direkt Marge ist. Und weil sie die Jahre hinter sich haben, in denen diese Arbeit nur Geld gekostet hat.

Warum es die großen Anbieter trotzdem gibt

Wer Serverhardware kauft, hat damit noch kein Geschäftsmodell. Damit hier aber kein falscher Eindruck entsteht: Meine fünf Premium-Gameserver-Hoster, die ich hier auf MC-GAMESERVER-MIETEN vergleiche, existieren teilweise seit über einem Jahrzehnt. Die machen das nicht aus Nächstenliebe. Mein Ergebnis sagt nicht, dass Gameserver-Hosting sich nicht rechnet. Es sagt, dass es sich in den ersten Jahren nicht rechnet und Skaleneffekte wichtig sind. Vier Hebel drehen die Rechnung, und alle vier brauchen Zeit.

Der erste ist die Abschreibung. Sobald die Hardware bezahlt ist, verschwindet der größte Brocken aus der Kalkulation. Ein EPYC-Node läuft wirtschaftlich fünf Jahre und länger, während er steuerlich nach der aktuellen Praxis für Computerhardware sehr viel kürzer angesetzt werden darf. Wie das im Einzelfall aussieht, gehört zu den Fragen, für die man einen Steuerberater bezahlt, ich bin keiner. Der wirtschaftliche Effekt ist eindeutig: Ab der zweiten Hälfte des fünften Jahres verdienst du an Maschinen, die abbezahlt sind, und dein Break-Even rutscht von 155 Servern deutlich nach unten. Zu den heutigen Speicherpreisen ist das allerdings knapp: Viereinhalb Jahre Amortisation bei einer Nutzungsdauer von etwas über fünf Jahren lassen nicht viel Zeit, in der die Hardware wirklich nur noch verdient.

Mit einer Einschränkung, die mir ein Betreiber mitgegeben hat: Hardware wird nicht kostenlos, nur weil der Kaufpreis wieder drin ist. Komponenten fallen aus, Anforderungen verändern sich, und irgendwann steht die nächste Generation an. Ein Teil des Überschusses ab Jahr fünf ist deshalb keine Marge, sondern Rücklage. Rechnet man das nicht ein, sieht das fünfte und sechste Jahr auf dem Papier besser aus, als es langfristig ist.

Der zweite ist die Skalierung. Ein großer Teil meiner Fixkosten wächst nicht mit. Buchhaltung, Rechtstexte, Versicherung, Monitoring, das Grundvolumen beim gefilterten Transit: Das zahlst du für drei Nodes fast genauso wie für sechs. Ein zweiter Cluster kostet dich, neben noch einmal 64.000 Euro Hardware, im Wesentlichen Housing, Strom und einen Aufschlag beim Transit, also grob 900 Euro im Monat, bringt aber wieder rund 3.750 Euro Umsatz. Aus 1.964 Euro Monatsergebnis werden so rund 4.578. Der zweite Cluster verdient deutlich besser als der erste, und der dritte nochmal besser.

Der dritte ist die Automatisierung, und der ist der eigentliche Engpass. Denn genau in dem Moment, in dem die Skalierung greift, verdoppelt sich auch die Ticketlast. Wer den zweiten Cluster ans Netz nimmt, bevor er den Support automatisiert hat, kauft sich einen Vollzeitjob mit Rufbereitschaft, keinen zusätzlichen Gewinn. Und selbst mit guter Automatisierung bleibt ab dieser Größe nur die Wahl zwischen Personal und Überlastung.

Der vierte ist die Streuung, und das ist der Hebel, den ich am meisten unterschätzt habe. Ein Anbieter mit fünfzig Spielen auf vierzig Knoten hat im Jahr vielleicht hundert große Patch-Tage, aber jeder einzelne trifft nur wenige Prozent seiner Flotte. Ich habe mit zwei Spielen vier bis sechs solcher Tage, und jeder trifft die halbe oder die ganze Flotte auf einmal. Um einen Valheim-Patchtag abzufangen, müsste ich auf jedem Knoten rund ein Drittel Reserve vorhalten, das ganze Jahr über. Ein großer Anbieter hält stattdessen einen einzigen Knoten als schwimmende Reserve und liegt damit bei zweieinhalb Prozent Gemeinkosten. Dieselbe Sicherheit zu einem Dreizehntel der Kosten. Dazu kommt, dass er weiß, welche Instanzen seit Wochen ausgeschaltet sind, und sie dichter packen kann. Eine gestoppte Instanz zu verschieben ist unkritisch, das ist ein Verzeichnis mit Weltdaten. Vorausgesetzt, er hat die Automatisierung dafür gebaut, und das ist derselbe Aufwand wie beim Panel.

Dazu kommt die Zusammensetzung des Portfolios. Wie viele Server überhaupt eingeschaltet sind, hängt vom Spiel ab: Bei einer gemeinsamen, dauerhaften Welt lässt man den Server laufen, bei einem Spiel, das man für eine Runde startet, nicht. Ein Betreiber nannte mir für Valheim eine deutlich höhere Betriebsquote als im Durchschnitt über sein gesamtes Angebot. Wer fünfzig Spiele anbietet, mischt also Dauerläufer mit Gelegenheitsspielen — und die Gelegenheitsspiele sind es, die dichte Knoten erst tragbar machen. Mein Modell besteht ausgerechnet aus zwei Dauerläufern. Das ist für einen Artikel die richtige Auswahl, für einen Cluster die ungünstigste.

Der mögliche Überbuchungsfaktor ist damit weder eine Charakterfrage noch eine Hardwarefrage. Er ist eine Funktion von Flottengröße und Automatisierung.

Rückmeldungen aus der Hoster-Praxis

Ich habe den Artikel vor der Veröffentlichung an mehrere Gameserver-Betreiber geschickt, mit der Bitte, meine Annahmen gegenzulesen. Einige Punkte habe ich direkt an den betreffenden Stellen eingearbeitet, Gegenpositionen hier unten, weil sie meiner Einschätzung widersprechen und du beide Seiten sehen sollst. Bestätigungen vermerke ich ebenfalls, denn auch das ist ein Ergebnis.

Mein Fazit

Angefangen habe ich mit der Frage, ob man mit Gameserver-Hosting Geld verdienen kann. Die Antwort ist ja, aber nicht so, wie ich dachte, und nicht in der Größenordnung, in der ich gerechnet habe. Drei Dinge sehe ich seit dieser Rechnung anders.

Erstens: Die Marge ist dünner, als das Preisschild vermuten lässt. Wenn 350 Server rund 1.964 Euro im Monat abwerfen, sind das 5,61 Euro pro Server. Wer dir zehn Slots für vier Euro verkauft, braucht entweder eine Flotte, gegen die mein Cluster ein Spielzeug ist, oder er spart an einer Stelle, die du beim Kauf nicht siehst.

Zweitens: Overselling ist nicht das Problem, die Reserve dahinter ist es. Jeder Anbieter überbucht. Der Unterschied zwischen einem seriösen und einem unseriösen liegt nicht im Ob und offen gesagt auch nicht im Faktor, sondern darin, wie viel Puffer im Peak übrig bleibt. Das kostet den Anbieter Geld, in meiner Rechnung 352 Euro im Monat, und es ist die eine Position, an der er sparen kann, ohne dass du es beim Kauf siehst. Was du als Kunde prüfen kannst: Wie fühlt sich der Server Freitag zwischen 20 und 22 Uhr an, nicht Dienstag um 14 Uhr? Bei Minecraft sagt dir /spark tps oder ein Timings-Report in dreißig Sekunden mehr als jede Werbeseite. Und wenn ein Anbieter dir einen Testzeitraum oder monatliche Kündigung anbietet, ist das ein stärkeres Qualitätssignal als jedes Hardware-Datenblatt.

Drittens: Welche Einheit ein Anbieter nimmt, sagt mehr über das Spiel als über den Anbieter. Wer nach Slots abrechnet, verkauft dir eine Obergrenze für Spieler. Wer nach RAM abrechnet, eine Obergrenze für Ressourcen. Welche davon die aussagekräftigere ist, hängt davon ab, welche Ressource bei dem Spiel überhaupt zuerst knapp wird.

Bei Minecraft ist das der Speicher. Wie viel eine Instanz braucht, schwankt zwischen zwei und sechs Gigabyte je nach Modpack, und genau diese Größe geht auf dem Knoten zuerst aus. Deshalb wird Minecraft praktisch überall nach RAM verkauft.

Bei Valheim ist es umgekehrt. Der Speicherbedarf ist fast konstant, die CPU-Grundlast fällt dagegen an, sobald der Server läuft, egal ob jemand spielt. Was du dort kaufst, ist nicht Rechenleistung, sondern die Größe deiner Runde. Und weil die Grundlast ohnehin anfällt, fängt Valheim in meinem Vergleich bei zehn Slots an: Ein Server mit zwei Slots würde den Anbieter fast dasselbe kosten. Diese Mindestgröße ist der sichtbarste Hinweis darauf, dass da eine Grundlast existiert, die mit der Spielerzahl nichts zu tun hat.

Dazu kommen Mischformen, bei denen Slots und RAM gemeinsam angegeben werden. Das ist keine Verschleierung, sondern der Versuch, beide knappen Ressourcen gleichzeitig abzubilden. Entscheidend ist am Ende weniger die Einheit als die Frage, ob der Anbieter seine Grenzen überhaupt offenlegt. Welches Modell für dich besser ist, hängt davon ab, ob deine Gruppe eher wächst oder eher mehr Mods will. Genau diesen Vergleich habe ich für die einzelnen Spiele im Minecraft-Preisvergleich und im Valheim-Preisvergleich aufgeschlüsselt.

Die Prozessoren sind bezahlbar geworden, der Rest nicht. Ein EPYC 9654 kostet heute nur noch einen Bruchteil seines Listenpreises, dafür ist der Arbeitsspeicher in einem Jahr sechsmal so teuer geworden und inzwischen der größte Einzelposten meiner Rechnung. Vor einem Jahr hätte derselbe Cluster rund 26.500 Euro gekostet, heute sind es 64.000. Wer kalkuliert, sollte die Zahlen aus meinem Sheet deshalb als Momentaufnahme lesen, nicht als Planungsgrundlage für die nächsten fünf Jahre. Und wer heute einsteigen will, sollte sich gut überlegen, ob er nicht erst einmal mietet, bis sich der Speichermarkt beruhigt hat.

Einen Nachteil habe ich beim Rechnen erst spät verstanden. Der Einsteiger kauft dieselbe Hardware wie der große Anbieter, darf aber weniger darauf verkaufen. Nicht weil er ehrlicher wäre, sondern weil ihm der Pool fehlt, über den sich Spitzen ausgleichen. Mit zwei Spielen auf drei Knoten trifft ihn jeder große Patch-Tag voll. Wer vierzig Knoten und fünfzig Spiele hat, merkt denselben Tag kaum. Dieser Unterschied steht in keiner Preisliste, und er lässt sich nicht wegoptimieren – man kann ihn nur lange genug aushalten, bis man selbst auf der anderen Seite steht.

Und auch wenn die Speicherpreise wieder fallen: Die Kunst des Gamehostings liegt 2026 nicht darin, die richtige Hardware zu kaufen. Sie liegt darin, den Support gar nicht erst entstehen zu lassen: durch Automatisierung und ein Interface, das so gut ist, dass der Kunde nicht auf die Idee kommt, ein Ticket zu schreiben.

Unmöglich ist es nicht. Wenn die Hardware deutlich länger hält als die viereinhalb Jahre, die sie zum Abbezahlen braucht, wenn du auf zwei oder drei Cluster skalierst und wenn du bis dahin ein Interface gebaut hast, das die Tickets gar nicht erst entstehen lässt, dann wird daraus ein tragfähiges Geschäft. Und wenn du es versuchen willst, dann in der Reihenfolge aus meiner Tabelle weiter oben: erst Reselling, dann ein gemieteter Rootserver, und die eigene Hardware ganz zum Schluss. Nur ist das kein Nebenprojekt für ein paar Abende, sondern eine Entscheidung über die nächsten fünf Jahre.

Ich werde kein Hoster. Ich miete mir stattdessen ganz entspannt meinen nächsten Windrose-Server, und ich freue mich seit dieser Rechnung ein wenig mehr darüber, dass sonntags um 19 Uhr jemand Kompetentes im Live-Chat sitzt, der mir hilft, wenn die Welt nicht laden will. Diese Person, die Filterhardware davor und die abbezahlten Nodes dahinter sind genau das, was in den zwölf Euro drinsteckt. Welche Anbieter ich nach dieser Rechnung guten Gewissens empfehle, steht in meinem Gameserver-Hoster-Vergleich.

Falls du selbst mal eine solche Rechnung aufgemacht hast und zu anderen Zahlen gekommen bist: Schreib mir. Ich rechne gern nach.

Wie ich gerechnet habe, meine Methodenbox

Damit du meine Zahlen prüfen und nicht glauben musst. Die komplette Kalkulation liegt offen, jede Annahme kann verändert werden: Excel-Datei ohne Makros. Lässt sich auch in Google Sheets, LibreOffice oder Numbers öffnen. Das Modell ist auf Englisch, weil ich es so gebaut habe, dass es auch außerhalb des deutschen Marktes jemandem nützt.

• Hardwarepreise: Günstigstes gelistetes Angebot auf Geizhals, Tray- und Bulk-Ware, Stand 25. Oktober 2026, auf netto umgerechnet. Arbeitsspeicher und Enterprise-SSDs schwanken derzeit stark; der Speicher allein macht rund 56 Prozent der Investition aus.
• Auslastungsannahme: 30 Prozent der laufenden Server haben im Peak Spieler. Eigene Schätzung auf Basis von Betreiberberichten in Hosting-Foren, keine erhobene Statistik. Davon zu unterscheiden ist der Anteil gebuchter Server, die überhaupt eingeschaltet sind — das Modell unterstellt hier konservativ hundert Prozent. Von den befragten Betreibern konnte die Belegungsquote niemand bestätigen; die einzige Angabe dazu betraf die andere Größe, nämlich den Anteil eingeschalteter Server.
• RAM-Bedarf: Valheim 1,5 GB im Leerlauf, bis 4 GB unter Last. Für den Leerlaufwert hat mir ein Betreiber einen gemessenen Median von 1,4 bis 1,6 GB genannt, mit Ausreißern bis 2,4; die Weltgröße schlägt dabei kaum durch. Minecraft 2 GB im Leerlauf bei nicht gepinntem -Xms, bis 6 GB unter Last — das sind Modellannahmen, keine Messwerte. Der reale Bedarf schwankt mit Spielerzahl, Mods, Serverlaufzeit und Serverversion.
• CPU-Bedarf: Valheim mit 1,0 Threads pro belegter und 0,8 pro leerer Instanz gerechnet. Die Werte stammen aus der Messung eines Betreibers auf Serverhardware; öffentliche Berichte von Desktop-CPUs nennen 35 bis 50 Prozent eines Kerns bei leerem Server, was bei Servertakt auf etwa dieselbe Größenordnung führt. Minecraft rechne ich weiter mit der zugeteilten Obergrenze von zwei vCPU unter Last und nahezu null im Leerlauf, weil dort nur geladene Chunks getickt werden. Im Sheet ist beides eine eigene Eingabezelle. Der Valheim-Wert ist die unsicherste Annahme im ganzen Modell.
• Bezugsgröße bei der CPU: gegen physische Kerne gerechnet, nicht gegen SMT-Threads. Zwei single-threaded Tick-Loops auf demselben Kern teilen sich dieselben Ausführungseinheiten, und das schlägt auf die Tickzeit durch. Gegen diese Bezugsgröße liegen beide Knotentypen über hundert Prozent: der Minecraft-Knoten bei 113, die Valheim-Knoten bei 117. Die 90 beziehungsweise 130 verkauften Server pro Knoten bleiben trotzdem so im Modell stehen; warum, steht im Abschnitt zum Overselling.
• Ticketquote: 13 Prozent der Kunden pro Monat. Ein eingespielter großer Anbieter nennt für Tickets per Mail einen niedrigen einstelligen Prozentsatz; ein Wert, der jahrelange Automatisierung voraussetzt.
• Reservierung: 32 GB pro Knoten für Host-System und ZFS-ARC abgezogen.
• Zahlungsgebühren: 0,35 Euro plus 2,49 Prozent pro Transaktion, gerechnet auf den Bruttoumsatz.
• Strompreis: 0,35 Euro netto pro Kilowattstunde. Marktüblich sind derzeit 0,33 bis 0,45 Euro, abhängig vom Rechenzentrum. Der im Stellplatzpreis enthaltene Anteil (typisch 50 VA oder 85 Watt pro Höheneinheit) ist für einen EPYC-Knoten nicht relevant.
• Gefilterter Transit: 400 Euro im Monat, geschätzt. Keiner der befragten Betreiber konnte dazu eine eigene Zahl beisteuern. Die Preise hängen stark vom zugesicherten Volumen und der Technik ab, nach oben ist viel Luft.
• Sensitivität: Die Concurrency-Tabellen entstehen durch Änderung genau einer Zelle im Modell. Die 315-Server-Variante hält die Peak-Auslastung konstant bei 83 Prozent und leitet die Verkaufsmenge daraus ab.
• Panel-Angaben: Stand Oktober 2026, geprüft gegen die offiziellen Projektseiten, Release-Listen und Sicherheitshinweise. Versionsstand, Lizenz und Advisories ändern sich schnell, prüf das vor einer Entscheidung selbst nach.
• Nicht enthalten als Aufwandsblock: Rechtsberatung und laufende Rechtspflege (Datenschutz, AGB, Widerruf, Auftragsverarbeitung, Missbrauchsmeldungen), die Entwicklung und Pflege der eigenen Plattform (Shop, Bestellprozess, Kundenportal, automatische Bereitstellung, Tarifwechsel, Benachrichtigungen) sowie die Arbeitszeit für die Kundengewinnung. Das Werbebudget selbst steckt in den 460 Euro für Verwaltung und Marketing. Das sind in der Startphase die größten Zeitfresser und sie lassen sich nicht sinnvoll allgemein in Euro pro Monat ausdrücken.
• Nicht enthalten: eigenes Gehalt, Personalkosten, Abschreibung auf die Hardware.
• Nicht kalkuliert: der Mietweg über Rootserver statt Kauf. Der senkt das Startkapital drastisch und die Marge ebenfalls.
• Modellversion: 1.2, Stand 25. Oktober 2026. Gegenüber 1.1 sind die Hardwarepreise auf den aktuellen Marktstand gebracht. Die Investition steigt dadurch von rund 26.000 auf rund 64.000 Euro, der Kapitalrückfluss ist über 72 statt 48 Monate gerechnet. Laufende Kosten und Monatsergebnis sind unverändert. Version 1.1 hatte den CPU-Bedarf pro Instanz und die Prüfung gegen die physischen Kerne ergänzt.

Wenn du in einer Position einen Fehler findest, sag Bescheid. Ich korrigiere den Artikel dann und schreibe dazu, was sich geändert hat.

Häufige Fragen zu meinem Rechenbeispiel