Pterodactyl vs. Pelican: auf welchem Game-Panel bauen Sie weiter?

Wenn Sie Gamehosting verkaufen, ist das die Entscheidung, die die nächsten Jahre Ihres Geschäfts prägt. Pterodactyl ist seit 2015 der Standard. Pelican ist ein Fork, im März 2024 von Leuten gestartet, die an Pterodactyl mitgearbeitet hatten, und er hat einen erheblichen Teil dieser Community mitgenommen.

Wir haben kein Interesse am Ausgang. Provibr unterstützt beide Panels live, und ein Kunde auf Pterodactyl zahlt uns genau dasselbe wie ein Kunde auf Pelican. Deshalb können wir das schreiben: cPanel veröffentlicht keinen ehrlichen Vergleich mit DirectAdmin, und Pterodactyl veröffentlicht keinen mit Pelican. Wir haben beide Integrationen gebaut, gegen beide APIs, und sind in beide Kantensammlungen gelaufen.

Die Zahl, um die es wirklich geht

Diese Werte stammen aus der GitHub-API und wurden am 21. August 2026 gemessen. In einem Jahr stimmen sie nicht mehr, und genau deshalb steht das Datum dabei.

Sterne und Forks messen, wie viele Menschen ein Projekt gefunden haben. Mitwirkende messen, wie viele noch daran arbeiten. Pelican hat in gut zweieinhalb Jahren mehr Mitwirkende gesammelt als Pterodactyl in zehn. Das ist die ganze Geschichte in einer Zeile, und deshalb wird diese Frage überhaupt gestellt.

Das Gegengewicht steht in der letzten Zeile, und es ist kein kleines. Pelican trägt weiterhin 1.0.0-beta, die Maintainer sagen das selbst, und die API ändert sich zwischen Beta-Releases. Provibr ist gegen 1.0.0 getestet und pinnt sonst nichts fest, denn das Panel bietet keine Möglichkeit zu erfragen, welche Version es ausführt. Ein Upgrade, das eine Antwort ändert, zeigt sich also als Fehler und nicht vorab als Warnung.

Was die beiden teilen

Pelican ist ein Fork, also ist die Form dieselbe. Ein Server wird aus einem Egg gebaut: einem Docker-Image, einem Startbefehl und einem Satz Variablen, die das Egg selbst definiert. Ein Node mit dem Wings-Daemon trägt den Container. Eine Allocation gibt dem Server seine Adresse und seinen Port. Beide Panels teilen ihre API in zwei Hälften: eine Verwaltungshälfte, die Server anlegt und löscht, und eine Client-Hälfte, die Power-Befehle, laufende Verbrauchswerte und die Konsole trägt.

Diese gemeinsame Form ist der Grund, warum eine Migration zwischen beiden überhaupt realistisch ist. Sie ist zugleich die Falle: dieselbe Form bedeutet nicht dieselben Antworten.

Wo sie auseinandergehen, gegen beide Panels gemessen

Das ist der Teil, den Ihnen keine Marketingseite gibt. Jede Zeile unten ist etwas, worauf wir beim Bauen und Ausrollen der beiden Integrationen gestoßen sind.

Ein paar davon verdienen einen Satz, denn sie entscheiden, wie viel Arbeit ein Wechsel tatsächlich ist.

Das Format der Egg-Regeln ist die schärfste Kante. Ein Parser, der gegen Pterodactyls Regel-Strings geschrieben wurde, scheitert bei Pelican nicht an einer Variablen. Er scheitert am Auspacken der gesamten Egg-Liste, weil sich der Typ geändert hat. Alles, was Eggs liest, muss neu geschrieben und nicht angepasst werden.

Der Unterschied bei Pflichtvariablen ist ein Unterschied in Supporttickets. Auf Pterodactyl wird ein fehlendes Feld vorab abgelehnt. Auf Pelican baut das Panel den Server, und das Spiel Ihres Kunden stürzt beim ersten Start ab. Provibr erzwingt diese Pflicht für Pelican deshalb auf der eigenen Seite: ein Feld, das rot wird, ist eine weit bessere Antwort als ein Container, der still stirbt.

Das CPU-Feld eines Nodes ist ein echter Fähigkeitsunterschied, zugunsten von Pelican. Ein Pterodactyl-Node meldet, wie viel Arbeitsspeicher frei ist; ein Pelican-Node meldet zusätzlich, wie viel CPU er hat und wie viel davon vergeben ist. Die Platzierung über Nodes kann also neben Arbeitsspeicher auch Kerne berücksichtigen. Zu dieser Zahl sollten Sie wissen: auf beiden Panels ist sie die eigene Buchführung des Panels (die Limits der Server auf einem Node zusammengezählt, einschließlich derer, die noch installieren) und keine Messung dessen, was läuft.

Beide Schlüsselpaare lassen sich vertauschen, ohne dass ein sichtbarer Fehler entsteht. Beide Panels akzeptieren einen Client-Schlüssel auch auf der Verwaltungs-API. Das Präfix ist das Einzige, was sie unterscheidet, und deshalb prüft jedes brauchbare Werkzeug es auf beiden Seiten. Pelican legt noch eine Schicht darauf: Der Client-Schlüssel ist genau einmal zu sehen, und die Liste behält danach eine kurze Kennung, die selbst als Schlüssel angenommen wird. Fügen Sie die ein, bekommen Sie einen nackten Authentifizierungsfehler, ohne jeden Hinweis darauf, dass Sie das Falsche kopiert haben.

Was sollten Sie also wählen?

Es gibt keinen allgemeinen Sieger. Es gibt einen Sieger je Situation.

Wählen Sie Pterodactyl, wenn Sie heute an zahlende Kunden verkaufen, Ihre Verträge etwas zur Softwarestabilität sagen oder Ihr Geschäft eine brechende Änderung in einem Minor-Release nicht auffangen kann. v1.15.1 erschien am 14. August 2026; das Projekt steht nicht still, es bewegt sich im Tempo einer zehn Jahre alten Codebasis mit 191 Mitwirkenden.

Wählen Sie Pelican, wenn Sie etwas Neues bauen, das 2027 live geht, wenn Sie eine Platzierung wollen, die CPU versteht, oder wenn Sie dort sein wollen, wo die Entwicklungsenergie derzeit liegt. Nehmen Sie dafür in Kauf, vor jedem Upgrade die Release-Notes zu lesen, und dass „Beta“ das eigene Wort des Projekts ist und nicht das eines Mitbewerbers.

Bleiben Sie vorerst auf Pterodactyl, wenn Sie es bereits produktiv betreiben und nichts wehtut. Dass ein Fork aktiver ist, ist ein Grund zu planen, kein Grund, in diesem Quartal zu migrieren.

Wechseln Sie zu Pelican, wenn Sie es bereits auf einer Testumgebung fahren, alles neu gebaut haben, was Eggs liest, und einen Rückweg besitzen, den Sie wirklich ausprobiert haben.

Was gern vergessen wird: Sie müssen nicht in einem Schritt wählen

Das Schwierigste an einer Panel-Migration ist nicht die Software. Es sind die Monate dazwischen, in denen alte Kunden auf dem alten Panel sitzen und neue Kunden auf dem neuen landen, und Sie zwei Steuerungsebenen betreiben, mit zwei Logins und zwei Arten zu zählen, was Sie verkauft haben.

Genau dort sitzt Provibr. Beide Panels verbinden sich mit demselben Provibr-Konto, beide erscheinen in derselben Serverliste, und beide zählen auf dieselbe Kapazität und dieselbe Monatsrechnung. Der Agent wählt sich aus Ihrem eigenen Netz nach außen, also muss keines der beiden Panels einen Port öffnen, und auf keinem wird etwas installiert. Server, die Sie nicht über Provibr angelegt haben, bleiben unangetastet, bis Sie sie importieren, und genau das macht aus dem Umzug eines bestehenden Panels ein Übernehmen statt eines Neuaufbaus.

Die Entscheidung, auf welches Panel Sie setzen, bleibt Ihre. Sie müssen sie nur nicht an einem Wochenende treffen.

Weiterlesen

• Pterodactyl einrichten: zwei Schlüssel, Eggs, Game-Pläne, die Konsole und Server importieren.
• Pelican einrichten: die zwei API-Schlüssel, Platzierung über Nodes und was sich zwischen Beta-Releases ändert.

Sterne, Forks, Mitwirkende und Releases wurden am 21. August 2026 über die GitHub-API gemessen. Alles, was hier über die beiden APIs steht, wurde beim Bau der Provibr-Integrationen gegen laufende Panels gemessen.