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 sowieso 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.

Die Frage hat mich also nicht mehr losgelassen, und ich habe getan, was man als Nerd eben tut: Ich habe vier Wochen lang alles gelesen, was ich zum Thema finden konnte. r/admincraft, r/Pterodactyl, r/HostingCompany, WebHostingTalk, LowEndTalk, ein paar deutsche Hoster-Discords, in denen man als stiller Mitleser eine Menge mitbekommt. Dazu Datenblätter, Geizhals-Preise, Colocation-Angebote und ein Taschenrechner, der irgendwann angefangen hat, mich zu hassen.

Was dabei rausgekommen ist, ist ausdrücklich kein Businessplan. Es fehlen darin Finanzierungskosten, ein Arbeitsplatz, Personalkosten und die Abschreibung auf die Hardware. Ich habe auch nicht vor, Hoster zu werden. 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.

Und weil die Frage naheliegt, warum ausgerechnet ein Preisvergleich darüber schreibt: Ich vergleiche hier seit Jahren Gameserver-Preise. Irgendwann wollte ich wissen, wie diese Preise überhaupt zustande kommen und was von zwölf Euro bei einem Anbieter tatsächlich ankommt. Diese Rechnung ist die Antwort darauf.

Wenn du selbst mal überlegt hast, ob man das nebenbei machen könnte, oder wenn dich einfach interessiert, was hinter dem Preisschild deines Servers steckt: Hier sind meine Zahlen, alle offengelegt, alle nachrechenbar.

Die komplette Kalkulation liegt als Tabelle offen, in der du jede Annahme selbst verändern kannst. Als Google Sheet oder als XLSX zum Herunterladen, Links stehen 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-Paketemunikation ü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.3-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.

Preise nach Geizhals-Niveau im Sommer 2026, Tray- und Bulk-Ware, Stand September 2026. Als Gewerbetreibender mit Vorsteuerabzug rechnest du netto, deshalb stehen hier Nettopreise.

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 genau deshalb ist High-End-Gamehosting überhaupt für kleine Anbieter machbar geworden. Wer hier auf die aktuellste Plattform schielt, verbrennt Geld für Leistung, die kein Minecraft-Server je abruft.

Weiterer Punkt, der leicht untergeht: 26.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 26.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 weh tut

Pterodactyl war jahrelang die selbstverständliche Antwort auf diese Frage. Panel plus Wings-Daemon in Go, verschlüsselte API, Docker darunter, praktisch jeder mittelgroße Anbieter setzt bis heute darauf auf.

Wer 2026 neu anfängt, startet aber nicht mehr dort. Pterodactyl ist nicht tot, aber im Maintenance-Modus: Sicherheitspatches kommen weiterhin, neue Funktionen praktisch keine. Der Unterschied zeigt sich am Rhythmus. Pelican veröffentlicht Releases im Wochenabstand, Pterodactyl 2026 im Monatsabstand. Pelican ist der Nachfolger, entwickelt vom selben Lead-Maintainer als sauberer Rewrite mit modernen Laravel-Praktiken, besserer Datenbankunterstützung und wartbarem Code.

Das Projekt startete Mitte 2024 als Fork, nachdem in der Community Sorge über eine lange Pause bei den Wings-Releases aufgekommen war, und behielt den vertrauten Workflow samt dem bestehenden Ökosystem an Server-Templates, den sogenannten Eggs.

Zwei Dinge haben den Wechsel beschleunigt, und beide sind für einen kommerziellen Hoster hochrelevant.

1. Das erste ist die Lizenz. Pterodactyl stand ursprünglich unter der permissiven MIT-Lizenz, unter der kommerzielle Hoster den Quellcode anpassen konnten, ohne ihre Änderungen offenlegen zu müssen. Mit dem Wechsel auf AGPLv3 änderte sich das: Wer ein öffentlich erreichbares Panel modifiziert, muss die Modifikationen offenlegen. Für jeden, der plante, sich ein eigenes Interface als Alleinstellungsmerkmal zu bauen, war das ein Schlag. Und hier ist der Haken, den man in Blogartikeln oft unterschlagen findet: Pelican steht ebenfalls unter AGPLv3. Der Lizenzwechsel war ein Auslöser für den Community-Frust, aber ein Ausweg ist Pelican in diesem Punkt nicht. Zwei Einschränkungen macht Pelican selbst deutlich: Private Panels sind von der Offenlegungspflicht nicht betroffen, und Plugins fallen nicht unter die Lizenz, weil sie den Panel-Quellcode nicht verändern. Betroffen ist also nur, wer ein öffentlich erreichbares Panel im Kern umbaut.
2. Das zweite ist Sicherheit. In Pterodactyls Verarbeitung von PHP-Übersetzungsdateien wurde eine schwere, nicht authentifizierte Remote-Code-Execution-Lücke gefunden. Übersetzungsdateien wurden als ausführbarer Code geparst, wodurch Angreifer beliebige Pfade laden und Code direkt auf der Hostmaschine ausführen konnten. Für einen Anbieter mit tausenden Kundenservern auf geteilten Nodes ist das kein Bug, das ist ein Existenzrisiko.

Die praktische Konsequenz für meine Kalkulation: Für Neuinstallationen ist Pelican die Wahl, weil dort aktiv entwickelt wird. Nur sollte man dazusagen, dass Pelican sich noch in der Beta befindet und eigene Sicherheitslücken gefunden und geschlossen werden, zuletzt im März 2026. Wer nicht innerhalb eines Tages nach einem kritischen Advisory patcht, tauscht ein bekanntes Risiko gegen ein neues.

Wer bereits auf Pterodactyl läuft, hat keine akute Eile. Und die Migration ist unangenehmer, als sie in Anleitungen klingt: In der Praxis muss man je nach Flottengröße mit dreißig bis neunzig Minuten kundensichtbarer Ausfallzeit rechnen. Die Werkzeuge sind 2026 deutlich besser geworden, ein Ein-Klick-Vorgang ist es für eine produktive Flotte trotzdem nicht. Die Eggs, also die Konfigurationsvorlagen pro Spiel, lassen sich dagegen weitgehend übernehmen.

Erwähnenswert ist noch, dass die Panel-Landschaft 2026 in Bewegung ist. Catalyst setzt auf Rust und containerd statt PHP und Docker und bringt ein echtes Plugin-System mit, daneben entsteht mit TheGamePanel ein weiterer Neuanfang. Ob sich davon etwas durchsetzt, weiß niemand. Für ein Gedankenexperiment mit 350 Servern würde ich Pelican nehmen: bekanntes Ökosystem, aktive Entwicklung, kein Migrationsrisiko bei den Eggs.

Kosten für das Panel: null. Pelican ist 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.

Kein Anbieter der Welt verkauft Ressourcen eins zu eins. 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.

Das Ganze funktioniert, weil Gamer asynchron spielen. Ein Valheim-Server im Leerlauf benötigt ungefähr anderthalb Gigabyte und nahezu keine CPU. Erst wenn Spieler drauf sind und Physik gerechnet wird, geht der Bedarf auf bis zu vier Gigabyte hoch. Und dass alle Kunden gleichzeitig online sind, kommt praktisch nie vor.

Meine Annahme für den Peak: dreißig Prozent gleichzeitig aktiv, Sonntagabend. 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 ist es entspannter. 130 Server à zwei vCPU wären 260 Threads auf 192, aber im Peak laufen nur 39 Server aktiv, also 78 Threads. Der Linux-Scheduler verteilt den Rest über CPU-Shares, und wer im Idle nichts braucht, gibt seine Zyklen frei.

Für Minecraft auf Node 1 sieht die Rechnung ä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 werden 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.

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 fünf Monate Amortisation, wenn du sie einpreist. Preist du sie nicht ein, kosten sie stattdessen deine Kunden 36 Gigabyte Puffer.

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.

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 UDP gar nicht erst annimmt. 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.

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. Der Traffic läuft dauerhaft durch Scrubbing-Hardware, die per Deep Packet Inspection auf Layer 7 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 gut dreizehn 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 zehn Monate, bis das Startkapital zurückgezahlt ist.

Macht 34 Monate. Fast drei Jahre, bis du zum ersten Mal Geld verdient hast, das dir gehört.

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. Nach Einkommen- und Gewerbesteuer und den eigenen Sozialabgaben bleiben davon realistisch 18 bis 20 Euro netto übrig. 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 inklusive Pauschalabgaben schnell 600 bis 700 Euro im Monat. Das ist ein Drittel deines Gewinns, für jemanden, der auch nicht rund um die Uhr da ist.

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. Das ist der 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.

Warum es die großen Anbieter trotzdem gibt

Damit hier 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 Jahr eins nicht rechnet und Skaleneffekte wichtig sind. Drei Hebel drehen die Rechnung, und alle drei 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 aber eindeutig: Ab Jahr vier verdienst du an Maschinen, die abbezahlt sind, und dein Break-Even rutscht von 155 Servern deutlich nach unten.

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 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.

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, macht daran entweder gar nichts 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 Abendpeak ü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: Der Unterschied zwischen Slot-Preis und RAM-Preis ist keine Marketingfrage, sondern eine Kostenfrage. Anbieter, die nach Slots abrechnen, verkaufen dir eine Obergrenze für Spieler. Anbieter, die nach RAM abrechnen, verkaufen dir eine Obergrenze für Ressourcen. Nach allem, was ich durchgerechnet habe, ist RAM die ehrlichere Einheit, weil sie dem entspricht, was auf dem Node tatsächlich knapp wird. Slots sind für Anfänger leichter zu verstehen, verschleiern aber, ob du für zwanzig Spieler auch die Rechenleistung für zwanzig Spieler bekommst. 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.

High-End-Hardware ist bezahlbar geworden. Ein EPYC-Cluster, für den man vor drei Jahren einen sechsstelligen Betrag gebraucht hätte, kostet heute 26.000 Euro. Ob das so bleibt, ist allerdings offen: Der KI-Boom treibt aktuell sowohl die Preise für Serverhardware als auch die Energiekosten, und beides sind die zwei größten Posten in meiner Rechnung. Wer heute kalkuliert, sollte die Zahlen aus meinem Sheet als Momentaufnahme lesen, nicht als Planungsgrundlage für die nächsten fünf Jahre.

Nur war Hardware ohnehin nie das Problem. Die Kunst des Gamehostings liegt 2026 nicht darin, die richtige CPU 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 nach drei bis vier Jahren abbezahlt ist, 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. 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 bisschen 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.

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

Wie ich gerechnet habe

Damit du meine Zahlen prüfen und nicht glauben musst. Die komplette Kalkulation liegt offen, jede Annahme kann verändert werden: im Browser ansehen und rechnen (Google Sheet, eigene Änderungen über Datei → Kopie erstellen) oder als XLSX herunterladen für Excel und LibreOffice, ohne Google-Konto. Das Modell ist auf Englisch, weil ich es so gebaut habe, dass es auch außerhalb des deutschen Marktes jemandem nützt.

• Hardwarepreise: Geizhals-Preisvergleich, Tray- und Bulk-Ware, Stand September 2026. Alle Angaben netto, da mit Vorsteuerabzug gerechnet.
• Auslastungsannahme: 30 Prozent gleichzeitig aktive Server im Sonntagabend-Peak. Eigene Schätzung auf Basis von Betreiberberichten in Hosting-Foren, keine erhobene Statistik.
• RAM-Bedarf: Valheim 1,5 GB im Leerlauf, bis 4 GB unter Last. Minecraft 2 GB im Leerlauf bei nicht gepinntem -Xms, bis 6 GB unter Last.
• 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.
• 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 September 2026, aus Projektdokumentation und Vergleichsberichten. Release-Rhythmus, Beta-Status und Migrationsaufwand ändern sich schnell, prüf das vor einer Entscheidung selbst nach.
• Nicht enthalten: eigenes Gehalt, Personalkosten, Abschreibung auf die Hardware, Finanzierungskosten und Zinsen, ein Arbeitsplatz mit Miete und Ausstattung, Einkommen- und Gewerbesteuer, Ausfallzeiten, Forderungsausfälle, Rechtsberatung bei Streitfällen. Das ist der Grund, warum das hier kein Businessplan ist, sondern eine Kalkulation der reinen Betriebswirtschaft.
• Nicht kalkuliert: der Mietweg über Rootserver statt Kauf. Der senkt das Startkapital drastisch und die Marge ebenfalls.
• Modellversion: 1.0, Stand September 2026. Bei Korrekturen ziehe ich die Version hoch und vermerke hier, was sich geändert hat.

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