Pelican zaczął jako fork Pterodactyla. Oba panele uruchamiają serwery gier w kontenerach Dockera i sterują nimi przez demona Wings na węzłach, ale różnią się w punktach, które dla firmy hostingowej ważą więcej niż wygląd panelu.
Pterodactyl i Pelican obok siebie
| Cecha | Pterodactyl | Pelican |
|---|---|---|
| Licencja | MIT | AGPL-3.0 |
| Wydania | stabilna linia 1.x, w 2026 roku od 1.12.0 do 1.15.1 | wersja 1.0 dochodzi przez kolejne bety |
| Baza panelu | MySQL albo MariaDB oraz Redis | domyślnie SQLite, do wyboru MySQL, MariaDB i PostgreSQL |
| Interfejs panelu | Laravel i front w React | Laravel i Filament, z rolami dla administratorów |
Licencja decyduje o własnych zmianach
MIT pozwala zmieniać kod Pterodactyla bez publikowania tych zmian. AGPL-3.0 wymaga, żeby zmodyfikowana wersja, z której użytkownicy korzystają przez sieć, oferowała im swój kod źródłowy. Hosting, który przerabia rdzeń Pelicana, musi więc udostępnić kod tych przeróbek swoim klientom.
Migracja z Pterodactyla
Pelican przejmuje bazę Pterodactyla na miejscu: użytkownicy, serwery, węzły, eggi i klucze API przechodzą, a serwery gier działają dalej na swoich plikach. Nie przechodzą motywy ani modyfikacje panelu: w Pelicanie takie zmiany buduje się jako wtyczki, które dodają funkcje bez ruszania plików rdzenia. Do Pelicana trafiła nasza poprawka aktualizacji wtyczek (#2598), więc ten mechanizm znamy od środka.
Gdy hosting chce sprzedawać serwery w panelu, w którym klient nimi zarządza, jest trzecia droga: Flaem łączy panel gier ze sklepem, portfelem i fakturami do KSeF, a działające węzły Wings przejmuje bez wyłączania serwerów.
Wdrożenie Pterodactyla, motyw i połączenie z billingiem opisuje strona integracji Pterodactyl.
Czy ten wpis był przydatny?
