Skip to main content

Architektur & Komponenten

Die Architektur von Pterodactyl folgt klaren Plattformprinzipien moderner IT-Systeme: Trennung von Control-Plane und Workloads, API-basierte Kommunikation, horizontale Skalierbarkeit und konsequente Isolation.

Ein fundiertes Verständnis dieser Architektur ist zwingend erforderlich, um Pterodactyl stabil, sicher und skalierbar zu betreiben.

1. Gesamtarchitektur – Überblick

Pterodactyl besteht aus zwei zentralen Hauptkomponenten:

  • Panel – zentrale Steuerungs- und Verwaltungsebene
  • Wings – Node-Daemon zur Ausführung der Game-Server

Diese Komponenten sind strikt voneinander getrennt und kommunizieren ausschließlich über definierte Schnittstellen.

Architekturprinzip:

Control-Plane ≠ Workload-Ebene

2. Das Panel – Control-Plane

Das Pterodactyl Panel stellt die zentrale Verwaltungsoberfläche dar. Es ist verantwortlich für:

  • Benutzer- und Rechteverwaltung
  • Server-Definitionen
  • Ressourcenlimits
  • API-Zugriffe
  • Kommunikation mit den Nodes

Das Panel führt selbst keine Game-Server aus und sollte niemals mit Workloads vermischt werden.

2.1 Technische Eigenschaften des Panels

  • Webbasierte Anwendung
  • Datenbankgestützte Konfiguration
  • API-First-Design
  • Stateless gedacht (abgesehen von DB)

Aus Plattform-Sicht ist das Panel ein klassischer Management-Service.

3. Wings – Node-Daemon

Wings ist der operative Teil von Pterodactyl. Er läuft auf jedem Node, der Game-Server ausführen soll.

3.1 Aufgaben von Wings

  • Starten und Stoppen von Containern
  • Durchsetzung von Ressourcenlimits
  • Log-Streaming
  • Statusmeldungen an das Panel

Wings ist direkt mit Docker verbunden und agiert als kontrollierte Schnittstelle zwischen Panel und Container-Runtime.

4. Kommunikation zwischen Panel und Nodes

Die Kommunikation erfolgt ausschließlich:

  • verschlüsselt
  • API-basiert
  • authentifiziert

4.1 Datenflüsse

  • Panel → Wings: Konfiguration & Steuerbefehle
  • Wings → Panel: Status, Logs, Metriken

Es existiert keine direkte Benutzerinteraktion mit Wings.

5. Container-Workloads

Jeder Game-Server läuft:

  • in einem eigenen Docker-Container
  • mit definierten Ressourcenlimits
  • isoliert von anderen Servern

Diese Isolation ist ein zentraler Sicherheits- und Stabilitätsfaktor.

5.1 Lifecycle eines Game-Servers

  1. Server wird im Panel definiert
  2. Wings erzeugt Container anhand des Eggs
  3. Container wird gestartet
  4. Laufzeitüberwachung durch Wings

6. Single-Node vs. Multi-Node-Architektur

6.1 Single-Node

Panel und Wings laufen auf demselben Server.

  • Einfacher Aufbau
  • Geeignet für Homelab & kleine Setups
  • Kein Skalierungsspielraum

6.2 Multi-Node

Panel und mehrere Wings-Nodes sind getrennt.

  • Horizontale Skalierung
  • Saubere Lastverteilung
  • Höhere Komplexität

Für produktive Hosting-Umgebungen ist Multi-Node Pflicht.

7. Sicherheitsrelevante Architekturentscheidungen

  • Kein direkter Zugriff von Benutzern auf Nodes
  • Keine Game-Prozesse auf Panel-Servern
  • Container-Isolation statt Shared User
  • API-Tokens statt Klartext-Zugriffe

Diese Architektur reduziert die Angriffsfläche signifikant.

8. Skalierbarkeit der Plattform

Pterodactyl skaliert nicht durch „größere Server“, sondern durch:

  • mehr Nodes
  • klare Ressourcenzuweisung
  • saubere Trennung der Komponenten

Die Plattform selbst bleibt dabei konstant.

9. Typische Architekturfehler

  • Panel und produktive Game-Server auf demselben Node
  • Keine Trennung von Management- und Workload-Netz
  • Unkontrollierter Zugriff auf Docker
  • Überlastete Single-Node-Setups

10. Fazit

Die Architektur von Pterodactyl ist klar, modular und an professionellen Plattformkonzepten orientiert.

Wer diese Architektur respektiert, erhält:

  • stabile Game-Server
  • skalierbare Strukturen
  • kontrollierbaren Betrieb

Wer sie ignoriert, betreibt lediglich ein weiteres Panel ohne Mehrwert.

Venasty Systems nutzt Pterodactyl ausschließlich innerhalb klar definierter Architektur- und Sicherheitsrichtlinien.

Back to top