Блог ·
Вибір ігрової панелі за її API
Шість ігрових панелей, виміряних за тим, що насправді дозволяють їхні API. Вирішальне питання не у функціях, а в тому, чи панель застосовує призупинення.
Автор: Provibr
Більшість порівнянь панелей для ігрових серверів написано для людини, яка клікатиме всередині однієї з них. Якщо ви збираєтеся продавати ігрові сервери, ви не та людина. Ви побачите панель приблизно двічі на рік, а ваша система білінгу бачитиме її кожні кілька хвилин, завжди.
Тож корисним є інше порівняння: що дозволяє робити API, чого він відмовляється вам сказати і яку з обіцянок інтерфейсу панель справді застосовує, коли клієнт перестає платити.
Усе нижче виміряно під час побудови інтеграцій проти Pterodactyl 1.11, Pelican 1.0.0-beta38, WISP 3.7.5, PufferPanel 3.0.9, GameAP 4.4.2 і MCSManager 10.18.2, у серпні 2026 року.
Однієї панелі в таблиці свідомо немає. AMP тут немає, бо ми його не міряли. Це розумний продукт зі справжнім API, і написати рядок порівняння з його документації, а не з його відповідей, було б рівно тим упевненим наповнювачем, проти якого ця стаття й аргументує.
Як зайти: шість панелей, пʼять моделей доступу
| Панель | Облікові дані | Примітки |
|---|---|---|
| Pterodactyl | Два статичні ключі, ptla_ і ptlc_ | Потрібні обидва |
| Pelican | Два статичні ключі, papp_ і pacc_ | Потрібні обидва |
| WISP | Один ключ, без префікса | Нічого перевірити до першого виклику |
| PufferPanel | OAuth2 client credentials | Непрозорий токен, година, scope admin |
| GameAP | Один bearer-токен Sanctum | У схемі панелі немає строку дії |
| MCSManager | Один ключ, заголовок x-request-api-key | Доступ до API усталено вимкнено |
Три з них потребують попередження.
Pterodactyl і Pelican потребують обох ключів, і причина структурна: в Application API немає ендпоінта живлення. Інтеграція, налаштована лише з ключем застосунку, може створювати сервери, які її власник не може запустити.
Pelican приймає клієнтський ключ в Application API. GET /api/application/servers, /nodes і /users усі повертають 200 з неправильним ключем, а помилка спливає лише на записі, як помилка валідації про відсутнє поле користувача. Pterodactyl відповідає 403 на той самий запит. У Pelican перевірка префікса ключа це єдиний спосіб зловити переплутану пару, перш ніж вона стане заплутаним збоєм під час провізіювання. У WISP, де префікса немає взагалі, зловити її неможливо.
MCSManager постачається з вимкненим API. У свіжій інсталяції enableApiKey виставлено в false, і доки хтось його не увімкне, кожен виклик повертає 403 «Insufficient Permissions», зокрема й виклики з дійсним ключем, що належить дійсному адміністраторові. Це тікет у підтримку в перший же день для кожного, хто не знає, куди дивитися. Поки ви там: MCSManager також обмежує швидкість вісьмома запитами на секунду на кожну сесійну куку, тож клієнт, який тримає куки, отримує тротлінг там, де клієнт, який їх викидає, не отримує.
Питання, що вирішує все: чи suspend щось робить?
Кожній із цих панелей можна наказати призупинити сервер. Питання не в цьому. Питання в тому, чи може клієнт, у якого досі є облікові дані до панелі, це скасувати.
| Панель | Механізм | Чи застосовує панель? |
|---|---|---|
| Pterodactyl | suspend / unsuspend в Application API | Так |
| Pelican | Так само | Так |
| WISP | Так само | Так |
| MCSManager | Час завершення в минуле, тоді вбити | Так |
| PufferPanel | Зупинити, тоді вбити | Ні |
| GameAP | Зупинити, тоді виставити blocked | Ні |
У трьох панелей родини Pterodactyl є справжній примітив, і обговорювати нема чого.
MCSManager це сюрприз. У нього теж немає ендпоінта призупинення, але є строк завершення: виставте час завершення екземпляра в минуле, і демон відмовиться його запускати. Ми перевірили це проти самої панелі, а не проти власної охорони, сирим запитом, і отримали 500 Instance expired. Unable to start the instance. Це і є застосування. Два застереження: екземпляр треба ще й убити, бо інакше запущений сервер працює далі, доки його не спіймає щогодинна перевірка строку, аж до шістдесяти хвилин потому. І якщо клієнт виставив власну дату завершення, повернути її на місце під час відновлення це вже ваша справа; наша поки що цього не робить.
У PufferPanel немає нічого. Немає ні ендпоінта призупинення, ні стовпця призупинення в моделі даних; словник статусів це running та installing. Найкраща доступна дія це зупинити сервер і вбити його, якщо він не зупиняється. Клієнт із доступом до панелі може натиснути «запустити».
У GameAP є прапорець, який нічого не робить. Є поле blocked, і виставити його можна лише адміністративно. Ми виставили його на запущеному сервері SA-MP, і сервер лишився онлайн, відповідав на живі ігрові запити й міг бути запущений з панелі знову.
Цю відмінність варто вбудувати у власну модель даних, а не згладжувати. На двох панелях, які цього не застосовують, чесним описом того, що сталося, є «сервер зупинено й заблоковано в панелі, але прямий вхід може запустити його знову», і це належить до запису аудиту дії. Записувати шість панелей як «призупинені», коли дві з них лише хотіли б такими бути, це те, як система білінгу тихо перестає збирати гроші.
Створення сервера: чотири різні форми
Спільної землі тут немає взагалі. Чотири з цих панелей моделюють ігровий сервер принципово по-різному, і форма виклику створення йде за цим.
Pterodactyl і Pelican хочуть усе одразу. Назву, власника, egg, образ docker, команду запуску, повний набір змінних середовища, зокрема ті, яких клієнт ніколи не бачить, limits, feature_limits і виділення. Часткового створення немає; відсутнє поле це відмова на кожне поле. Одне значення варто знати: limits.io валідується як between:10,1000, тож надіслати 0 для «безлімітно» це 422 на полі, про яке жоден клієнт ніколи не почує. Pelican це правило перевернув: там 0 нормально, а помилкою є пропуск поля.
PufferPanel вивернутий навиворіт. Ви самі карбуєте ідентифікатор сервера, вісім символів, а тоді робите PUT усього визначення шаблона вбудовано, бо список шаблонів не несе змінних. Створення не встановлює: це другий виклик. А видалення вимагає спершу зупинити, інакше ви отримаєте 500.
GameAP створює рядок у базі даних і більше нічого. POST /api/servers дає вам сервер з installed: 0; встановлення це другий виклик, чий результат приземляється в завданні демона, а не у відповіді HTTP, тож ви опитуєте. Немає ні зовнішнього ідентифікатора, ні ключа ідемпотентності, а назви не унікальні, що разом означає, що повторене створення тихо дає дублікат. Повернутий ідентифікатор це єдина ідентичність, яку ви отримуєте, тож збережіть його раніше, ніж щось інше встигне піти не так.
У MCSManager немає поняття шаблона взагалі. Екземпляр це команда запуску, і це вся абстракція. Є список пресетів швидкого встановлення, шістдесят три штуки, але жоден не несе ідентифікатора: панель зіставляє за заголовком плюс описом, пʼятдесят із шістдесяти трьох заголовків не унікальні, а значення залежать від мови. Усе, що на них завʼязано, ламається, коли клієнт змінює мову панелі.
Що видно потім
| Панель | Показники використання | Ємність вузла | Жива консоль |
|---|---|---|---|
| Pterodactyl | CPU, памʼять, диск, мережа, аптайм | З вузла | Так |
| Pelican | Так само | З вузла | Так |
| WISP | Так само, без аптайму | Ємність так, зайнятість ні | Так |
| PufferPanel | Лише CPU й памʼять | Не повідомляється | Опитування, не потік |
| GameAP | Немає | Не читається, 403 | Окремий протокол |
| MCSManager | CPU й памʼять; диск завжди 0 | На демон | Socket.io, не WebSocket |
Два записи там гірші, ніж мають вигляд. GameAP повертає 403 на /api/nodes для токена API, тож рушій розміщення взагалі не бачить ємності, і йому треба казати, куди що класти. А цифра диска в MCSManager не просто ненадійна: поле оголошено як нуль у демоні й ніколи не присвоюється, тож воно завжди нуль, на кожному екземплярі, назавжди.
Ендпоінт /resources у Pterodactyl кешується двадцять секунд, і це важить більше, ніж звучить: опитуйте частіше, і ви отримаєте ті самі байти назад, а наївний розрахунок швидкості мережі перетворює однакові лічильники на провал, якого не було. Pelican успадкував ту саму поведінку. WISP цього не кешує, але у WISP немає поля аптайму, а саме це поле ви використали б, щоб відрізнити свіже показання від повтореного.
Як обирати насправді
- Вам потрібні застосовне призупинення й справжній API. Pterodactyl або Pelican, якщо хочете форк, що активно розвивається. Це нудна правильна відповідь для більшості тих, хто продає ігровий хостинг.
- Вам потрібен хостинг без Docker на невеликих машинах. MCSManager, і він пасує краще, ніж підказує його репутація, бо строк завершення дає справжнє застосування. Прийміть, що ви отримаєте дві метрики використання й жодної інтеграції з консоллю.
- У вас уже працює PufferPanel чи GameAP. Гаразд, але будуйте призупинення зверху: платформа має блокувати доступ до панелі, бо панель цього не зробить.
- Ви обираєте сьогодні, без спадку. API панелі буде обмеженням вашої автоматизації на роки вперед, а дві з цих шести не можуть застосувати ту єдину операцію, від якої найбільше залежить ваша система білінгу.
Що тут не виміряно
AMP, як сказано вище. Версії Pterodactyl нижчі за 1.11, на панелі, де це саме той вид поведінки, що зсувається в патчових випусках. Ліміти швидкості на Pterodactyl і Pelican, для чесного встановлення яких знадобилися б сотні запитів до живої панелі. MCSManager з увімкненим Docker, де метрик мало б бути більше, але де ми жодного разу не бачили заповненого поля. І класичний GameAP на PHP, оскільки панель, яку ми міряли, це переписаний варіант на Go, що відрізняється принаймні своїм шаром автентифікації.
Provibr інтегрує всі шість цих панелей через агента, що працює всередині вашої власної мережі; нотатки з налаштування є під Pterodactyl, Pelican, PufferPanel, GameAP і MCSManager.