Blog-Übersicht
Engineering · Infrastruktur ≈ 9 Min. Lesezeit

Game-Hosting-Plattform selbst bauen: Pterodactyl-Alternative von 0 bis Live

Von Ayoub Boubakri · 09Clicks · Veröffentlicht am

Fast jeder Game-Hoster auf dem deutschen Markt nutzt Pterodactyl mit einem weiß-gelabelten Frontend. Das funktioniert – aber es ist 2015er-Software-Architektur. Wir haben für Renzom eine eigene Hosting-Engine gebaut. Hier ist die Architektur und die Entscheidungen dahinter.

  • Game Hosting
  • Linux
  • Stripe
  • Provisioning
  • Custom Panel

Warum nicht einfach Pterodactyl?

Pterodactyl ist ein solides Open-Source-Projekt. Die meisten Game-Hoster setzen es ein, weil es schnell ist – ein Re-Seller-Stack ist in 2 Wochen live. Das ist auch genau das Problem: Wer Pterodactyl nutzt, hat in der Regel:

  • Ein Frontend-Theme, das jeder andere Hoster auch hat (Pterodactyl-Daemon-Layout ist unverkennbar).
  • Eine PHP/Laravel-Codebasis, die nicht zu Ihrem restlichen Stack passt.
  • Eine UI, die für Admins gebaut ist, nicht für Endkunden.
  • Limitierte Möglichkeit, eigene Features (Multi-Tenant-Logik, Marketplace, KI-Integration) sauber draufzubauen.

Wenn Sie ein Produkt bauen wollen – nicht nur ein Re-Seller – brauchen Sie eigene Software. Das ist nicht für jeden der richtige Weg, aber es ist der Unterschied zwischen Vendor und Plattform.

Die Renzom-Architektur in einem Bild

[ Browser / Spieler ]
        ↓
[ Next.js Frontend (Vercel) ]
        ↓ (REST + Auth-Tokens)
[ Application API (TypeScript / Prisma) ]
        ↓                    ↓
[ Stripe Webhooks ]   [ Provisioning Queue ]
                              ↓
                    [ Hosting-Engine (Dedicated) ]
                              ↓
                    [ Container-Lifecycle / FS / Net ]
                              ↓
                    [ Game-Server-Prozess ]

Vier Schichten: Edge, Application, Provisioning, Runtime. Jede mit klarer Verantwortung, jede separat skalierbar.

Schicht 1: Bare-Metal Linux statt Cloud

Game-Server sind CPU-bound (Single-Thread-Performance entscheidet) und brauchen niedrige Latenz. AWS / Hetzner Cloud sind oft schlechter als ein guter Dedicated-Server, weil Sie auf Shared-CPUs landen.

Renzom läuft auf Dedicated-Servern in einem deutschen Rechenzentrum:

  • AMD Ryzen mit hoher Single-Thread-Leistung (für Minecraft / Valheim entscheidend).
  • NVMe für World-Saves und Plugin-Daten.
  • 1 Gbit symmetric mit DDoS-Schutz auf Netzwerk-Ebene.
  • Hardened Linux mit ufw, fail2ban, automatischen Security-Patches.

Kosten: Vorhersagbar, monatlich. Kein „AWS-Bill-Schock“ am Monatsende, weil ein Spieler eine Stunde lang einen Tunnel-Bug ausgenutzt hat.

Schicht 2: Hosting-Engine mit Container-Lifecycle

Das Herzstück. Eine Hosting-Engine muss vier Operationen sauber können:

  1. Create: Neuen Game-Server provisionieren – Image laden, Port allocieren, Filesystem initialisieren, Limits setzen.
  2. Start / Stop / Restart: Lifecycle-Steuerung mit Logging und Crash-Recovery.
  3. Scale Up / Down: Ressourcen-Limits anpassen (RAM, CPU, Disk).
  4. Destroy: Sauber zurückbauen – Filesystem, Ports, Quotas, Backups.

Wir haben die Engine in Go implementiert – nahe am Linux-Kernel, schnell, statisch kompiliert, kein Runtime-Drama. Sie kommuniziert über eine interne API mit der Application-Schicht. Container-Lifecycle läuft über LXC / Docker, je nach Game.

Wichtig: Die Engine ist idempotent. Wenn die Application zweimal „create“ ruft, passiert nur einmal etwas. Das spart bei verteilten Systemen unzählige Bugs.

Schicht 3: Stripe-Provisioning ohne manuellen Schritt

Klassischer Hoster: Kunde bezahlt → Mail an Support → Support provisioniert manuell → Kunde wartet 30 Minuten.

Renzom: Kunde bezahlt → Stripe-Webhook → Provisioning-Queue → Hosting-Engine → Server live → Bestätigung per Mail + Discord. Gesamtzeit: typisch unter 5 Minuten. Komplett ohne manuellen Eingriff.

Diese Pipeline ist nicht trivial. Sie muss überleben:

  • Stripe-Webhook-Re-Tries (Idempotenz, siehe unser Stripe-Blog).
  • Engine-Crashes während Provisioning (Recovery aus letztem konsistenten State).
  • Race-Conditions, wenn Kunden zwei Server fast gleichzeitig kaufen.
  • Refunds, die schon provisionierte Server wieder destroyen müssen.

Schicht 4: Spieler- & Admin-Panel

Hier trennt sich „Re-Seller-Stack“ von „eigenem Produkt“. Das Panel ist das Gesicht. Wir haben es als Next.js-App mit folgenden Anforderungen gebaut:

  • Server-Verwaltung: Start / Stop / Restart, Live-Konsole, Datei-Manager, Backup-Steuerung.
  • Subscription-Management: Upgrade / Downgrade ohne Service-Unterbrechung.
  • Mehrsprachig: i18n von Anfang an, weil EU-Spieler nicht alle Deutsch sprechen.
  • Mobile-Ready: Spieler restarten ihren Server vom Handy aus, nicht vom Desktop.
  • Discord-Integration: Server-Status-Updates, Login-Verknüpfung.

Frontend → API → Engine → Container → Spiel-Prozess. Vier Hops, niedrige Latenz, kein „seit 5 Minuten lädt die Konsole“.

Operations: Was Sie unterschätzen werden

Die ersten 90% bauen Sie in Wochen. Die letzten 10% kosten Monate, weil sie operationale Tiefe brauchen:

  • Monitoring: Welche Server crashen wie oft? Welche User verbrauchen mehr CPU als ihr Plan erlaubt?
  • Backup-Strategie: Tägliche World-Saves, Restore-Drill, Off-Site-Storage.
  • Abuse-Detection: Wer nutzt Game-Server für Crypto-Mining oder DDoS-Reflection?
  • Capacity-Planning: Wann braucht es einen zweiten Server-Knoten?
  • Support-Workflows: Tickets aus Discord, automatische Diagnostik, Eskalations-Pfade.

Genau diese Operations-Schicht ist der Grund, warum die meisten Hoster nicht selbst bauen. Sie unterschätzen, was nach dem ersten „Server läuft“ kommt.

Lessons aus der Production

  • Bauen Sie idempotent von Tag 1. Sonst zahlen Sie es später dreifach.
  • Stripe ist die Source-of-Truth für Subscriptions. Ihre DB ist der Cache, nicht andersrum.
  • Spieler interessiert nicht, dass Sie eigene Software haben – sie wollen, dass „Server läuft, Konsole reagiert“. UX-Tiefe schlägt Tech-Tiefe.
  • Multi-Lang macht den Unterschied zwischen DACH-Hoster und EU-Player. i18n von Anfang an, nicht nachträglich.
  • DDoS-Schutz auf Netzwerk-Ebene ist Pflicht, nicht „nice to have“. Game-Server sind beliebte Ziele.

Wann sollten Sie selbst bauen?

Selbst bauen lohnt sich, wenn:

  • Sie eine Marke aufbauen wollen, kein Re-Seller-Geschäft.
  • Sie eigene Features brauchen, die Pterodactyl nicht abbildet (Marketplace, KI-Integration, Cross-Game-Logik).
  • Sie Engineer-Tiefe verfügbar haben (eigenes Team oder Partner wie 09Clicks).
  • Sie Mehrjahres-Horizont haben – nicht „in 6 Wochen launchen“.

Selbst bauen lohnt sich nicht, wenn Sie nur einen Test-Markt validieren wollen oder kein Engineering-Team haben.

Fazit: Eigenes Hosting ist Engineering, kein Konfigurations-Job

Eine eigene Game-Hosting-Plattform zu bauen ist ein Vollzeit-Engineering-Projekt für 4–8 Monate – je nach Scope. Das Ergebnis ist ein Produkt, nicht ein Re-Seller-Stack. Bei Renzom sehen wir das Tag für Tag: eigene Brand, eigenes UX, eigene Roadmap, keine Plattform-Abhängigkeit.

09Clicks hat Renzom als 09Clicks-Eigenproduktion gebaut. Wenn Sie selbst eine Plattform planen – Game-Hosting, SaaS, Marketplace – sprechen wir gern darüber, wo Engineering-Tiefe Sinn macht und wo Pterodactyl-Style-Boilerplate ausreicht.

Eigene Plattform planen?

Game-Hosting, SaaS, Marketplace, Custom-Panel: Wir bauen End-to-End mit Festpreis-Anker und transparenter Roadmap.

Plattform anfragen Renzom Case-Study Pakete & Preise

Ähnliche Artikel