Gameserver-Panel mit Pterodactyl: Panel, Node, Trennung

Wer mehr als zwei Spielserver betreibt, für einen Verein, eine Community oder Kunden, kommt an einer Verwaltungsoberfläche nicht vorbei. Pterodactyl ist die verbreitetste freie Lösung: ein Panel für Menschen und ein Daemon auf jeder Maschine, der die Container startet.

Der Beitrag beschreibt die Architektur und die Entscheidungen, nicht jeden Installationsbefehl, den offiziellen Installationsweg gibt es beim Projekt selbst, und er ändert sich häufiger als die Struktur.

Zwei Teile, zwei Vertrauensstufen#

	Panel	Daemon (Wings)
Was es ist	Weboberfläche, Benutzer, Rechte, Datenbank	startet und überwacht die Spiel-Container
Wer spricht damit	Menschen im Browser	nur das Panel, über eine API
Braucht	PHP, Datenbank, Redis	Docker, viel RAM, schnelle Platte
Wenn es ausfällt	niemand kann verwalten	die Spielserver stehen

Panel und Spielserver gehören nicht auf dieselbe Maschine

Läuft beides zusammen, trifft ein Angriff auf einen Spielserver auch die Verwaltung und ein Lastspitzen-Abend auf dem Spielserver macht das Panel unbenutzbar. Getrennt bleibt die Verwaltung erreichbar, während vorn gefiltert wird. Dieselbe Regel wie in Gameserver unter Beschuss: Verwaltung auf eine andere Adresse.

Der übliche Aufbau für den Anfang: Panel auf einem kleinen VPS, Daemon auf der Maschine mit der schnellen CPU (Takt schlägt Kerne).

Was das Panel braucht#

Webserver mit TLS. Das Panel gehört hinter einen Reverse-Proxy (Caddy oder nginx), nicht direkt ins Netz.
Datenbank. MariaDB reicht; die Einstellungen aus MariaDB-Fallen gelten unverändert.
Redis für Sitzungen und Warteschlangen.
Einen Warteschlangen-Arbeiter als systemd-Dienst. Ohne ihn scheinen Aktionen zu hängen: Der Auftrag wird angenommen und nie ausgeführt, einer der häufigsten „Panel kaputt“-Fälle, der keiner ist.

# /etc/systemd/system/pteroq.service — sinngemäß
[Service]
User=www-data
Restart=always
ExecStart=/usr/bin/php /var/www/pterodactyl/artisan queue:work --queue=high,standard,low --sleep=3 --tries=3

Warum ein Timer hier nicht reicht und wie man den Zustand sichtbar macht: systemd-Timer statt Cronjob.

Was der Daemon braucht#

Docker, und dann Ports mit klaren Rollen:

Port	Wofür	Von wo erreichbar
8080/tcp	API zwischen Panel und Daemon	nur vom Panel
2022/tcp	SFTP für Kundendateien	vom Kunden, gern begrenzt
Spielports	die eigentlichen Server	offen, mit Drossel

# Die API gehört nicht ins Internet — nur die Panel-Adresse darf sie sehen:
nft add rule inet filter input ip saddr != <panel-ip> tcp dport 8080 drop

Noch besser: Panel und Daemon reden über einen WireGuard-Tunnel statt über das offene Netz. Dann ist Port 8080 von außen gar nicht erst sichtbar.

Die Trennung, die Kunden nicht sehen sollen#

Pterodactyl gibt Kunden Zugriff auf ihren Container: Dateien, Konsole, Neustart. Was sie nicht bekommen dürfen:

Root auf dem Host. Klingt selbstverständlich, wird aber unterlaufen, wenn man Spielserver mit erweiterten Rechten startet, weil eine Modifikation es „braucht“.
Zugriff auf fremde Verzeichnisse. Jeder Server bekommt sein eigenes Datenverzeichnis; Symlinks nach außen sind der klassische Ausbruchsversuch.
Beliebige Abbilder. Wer eigene Docker-Abbilder erlauben will, erlaubt fremden Code auf der Maschine. Für Kunden bleibt die Liste kuratiert.

# Nachsehen, was tatsächlich läuft und mit welchen Rechten:
docker ps --format '{{.Names}}\t{{.Image}}'
docker inspect $(docker ps -q) | jq -r '.[] | "\(.Name) privileged=\(.HostConfig.Privileged)"'

Ein privileged=true in dieser Ausgabe ist ein Befund, kein Detail.

Sichern#

Zwei Ebenen, wie überall:

Die Weltdaten der Spielserver, häufig, weil sie nicht reproduzierbar sind (Survival-Server über SteamCMD beschreibt den Rhythmus).
Die Panel-Datenbank, sie enthält Benutzer, Zuordnungen und Zugänge. Ohne sie ist die Zuordnung „welcher Container gehört wem“ weg, selbst wenn alle Daten noch da sind.

mariadb-dump --single-transaction panel | gzip > /backup/panel-$(date +%F).sql.gz

Die Regeln dazu stehen in Datenbank sichern und wirklich zurückspielen und 3-2-1.

Updates#

Panel und Daemon müssen zusammenpassen. Die Reihenfolge, die sich hält:

Sicherung von Datenbank und Konfiguration.
Panel aktualisieren, Migrationen einspielen, Warteschlangen-Dienst neu starten.
Daemon aktualisieren.
Einen Testserver starten und stoppen, bevor Kunden es tun.

Ein Panel, das eine neuere Daemon-Version erwartet als installiert ist, zeigt Server als „offline“, obwohl sie laufen. Das ist die häufigste Verwirrung nach einem halben Update.

Häufige Fragen#

Lohnt sich Pterodactyl für zwei Server?#

Selten. Zwei Server sind mit systemd-Units einfacher zu betreiben. Ab einer Handvoll, und besonders sobald andere Menschen Zugriff brauchen, dreht sich das Verhältnis.

Kann das Panel auf demselben VPS wie meine Website laufen?#

Kann es. Es teilt sich dann aber Webserver, PHP und Datenbank mit der Website und ein Update dort kann das Panel treffen. Getrennte Container sind der ruhigere Weg.

Wie viele Server trägt eine Node?#

Das entscheidet der Arbeitsspeicher, nicht das Panel. Überbuchen funktioniert, solange nicht alle gleichzeitig voll sind und geht genau dann schief, wenn es zählt.

Was ist mit Alternativen?#

Es gibt mehrere freie und kommerzielle Panels, und die Nachfolgeentwicklung von Pterodactyl selbst. Die Architektur, Panel getrennt vom Daemon, Container je Server, ist bei allen ähnlich; die Entscheidungen in diesem Beitrag gelten also weiter.

Brauche ich einen eigenen Docker-Aufbau dafür?#

Nein, der Daemon bringt seinen mit. Was du brauchst, ist Verständnis der Netze darunter, sonst sind Ports offen, von denen du nichts weißt (Container-Netze verstehen).

Kurz gesagt#

Panel und Daemon trennen, verschiedene Maschinen, verschiedene Vertrauensstufen.
Die API zwischen beiden gehört nicht ins Internet, am besten in einen Tunnel.
Der Warteschlangen-Dienst ist Pflicht; ohne ihn hängen Aktionen still.
Kunden bekommen ihren Container, keine erweiterten Rechte und keine freien Abbilder.
Sichern heißt hier Weltdaten und Panel-Datenbank, nicht nur eins davon.