Блог ·
Як продавати вебхостинг із CyberPanel
У CyberPanel є API, але створення сайту повідомляє про успіх, ще нічого не знаючи. Що API повертає, які пастки кусають першими та як на цьому будувати.
Автор: Provibr
CyberPanel є панеллю, яку хостери на OpenLiteSpeed найчастіше називають поруч із DirectAdmin. Виміряно на GitHub 21 серпня 2026 року: 2007 зірок, 723 форки та 362 відкриті тікети, при повільнішому темпі випусків, ніж у більшості аналогів.
У неї є REST API, і все, що потрібно, щоб продавати на ній хостинг (створити сайт, призупинити його, змінити пакет, видалити), є частиною цього API. Чого в неї немає, так це чогось, що вирішує, коли ці речі робити, а що в неї таки є, так це набір відповідей, які легко прочитати хибно.
Перш за все: доступ до API вимкнено
На свіжому CyberPanel API вимкнено, і це стосується й вашого головного адміністратора. Ви вмикаєте його в Users → API Access для користувача admin. Більше нічого не потрібно; ви входите з обліковими даними, які вже маєте.
Лишіть його вимкненим, і кожен виклик повертається як API Access Disabled., хоч би що ви надіслали. Пів дня коштує саме порядок перевірок: CyberPanel перевіряє цей прапорець перед тим, як перевірити пароль, тож із вимкненим прапорцем правильний і хибний паролі повертають однаковий 403. Усе вказує на ваші облікові дані, тоді як проблема лежить на одну галочку далі.
Щойно прапорець увімкнено, контракт під ним чистий і справді корисний:
correct password → HTTP 200 {"verifyConn": 1}
wrong password → HTTP 401 {"verifyConn": 0, "error_message": "Invalid password."}
unknown user → HTTP 404 {"error_message": "Administrator not found."}Три ситуації, три різні дії для клієнта, і всі розрізняються.
Адміністратор має називатися admin
Це не налаштування, а умова, і вона походить від самого CyberPanel, а не від чогось збудованого над ним. Частину його API охороняє буквальна перевірка імені, яка відхиляє кожного користувача, крім admin, і саме ця частина перелічує сайти на панелі й повідомляє, наскільки просунулося створення нового.
Обидва неминучі, якщо ви хочете продавати на ній хостинг: вам потрібен список, щоб знати, що існує, і потрібне повідомлення про поступ із причини, викладеної в наступному розділі. Перейменований адміністратор непридатний, і все, що ви будуєте, має сказати про це під час перевірки підключення, перш ніж перше замовлення зʼясує це за вас.
Обліковим записом є домен, а не логін
Це структурна відмінність від DirectAdmin, cPanel і Virtualmin, і вона змінює те, як ви моделюєте продукт.
Запис сайту в CyberPanel має унікальне поле domain, і кожна команда цілиться в нього: видалення бере domainName, призупинення та зміна пакета беруть websiteName, і всі три шукають сайт за доменом. Немає логіна, до якого можна звернутися. Unix-користувач генерується, а не обирається: пʼять літер, витягнутих із домену, плюс чотири випадкові цифри. Виміряно для provibr-test-1.example.com: provi7346, і домашній каталог названо за доменом, а не за користувачем. Ви не можете обрати це імʼя, не можете його передбачити, і воно зʼявляється рівно в одній відповіді API й у жодному переліку взагалі.
Один наслідок варто знати ще до вашого сотого облікового запису: створення сайту створює під ним і панельний логін, з увімкненим доступом до API, і цей логін переживає видалення сайту. Виміряно після видалення: unix-користувача немає, домашнього каталогу немає, vhost немає, рядка в базі даних немає, а логін власника ще на місці. Шлях очищення CyberPanel охороняє перевірка, яка не може успішно завершитися в момент свого виконання, і отриману помилку проковтнуто. Якщо ніщо над панеллю його не прибирає, кожен скасований клієнт лишає по собі логін.
Створення сайту повідомляє про успіх, ще нічого не знаючи
Це найважливіше, що треба зрозуміти про API CyberPanel.
createWebsite відповідає приблизно за три секунди так:
{"status": 1, "createWebSiteStatus": 1, "error_message": "None",
"tempStatusPath": "/home/cyberpanel/2424", "LinuxUser": "provi7346"}Це надходить іще до того, як зроблено більшу частину роботи: кінцева точка будує командний рядок, запускає його не чекаючи й повертається. Справжній поступ живе у файлі стану, який читається окремим викликом. Виміряно, одне справжнє створення:
+ 2.8s 10% Creating DNS records..
+ 4.8s 25% Setting up directories..
+ 6.9s 70% Setting up SSL.. ← sits here for 28 seconds
+35.3s 80% Creating mail child domain..
+49.5s 100% Website successfully created. [200]Приблизно пʼятдесят секунд, з яких близько двадцяти восьми припадає на спробу SSL, яку панель робить хоч би що ви надіслали: API безумовно перекриває цей прапорець, тож немає способу створити сайт без нього. На домені, який ще публічно не резолвиться, це двадцять вісім секунд очікування сертифіката, який не надійде.
І перша відповідь не є вироком. Виміряно з навмисно хибними даними:
| Випадок | Відповідь HTTP | Що насправді сталося |
|---|---|---|
| Домен уже існує | createWebSiteStatus: 1 (успіх) | This website already exists. [404] у файлі стану |
| Невідомий пакет | createWebSiteStatus: 1 (успіх) | Package matching query does not exist. [404] |
| Некоректний домен | createWebSiteStatus: 0, "Invalid domain." | відхилено одразу |
| Некоректний email | createWebSiteStatus: 0, "Invalid email." | відхилено одразу |
Одразу перевіряється лише форма домену та email. Чи вільний домен і чи існує пакет, видно тільки у файлі стану. Інтеграція, яка вірить першій відповіді, повідомить про успішне замовлення домену, який уже було зайнято.
Ще дві деталі роблять опитування важчим, ніж здається. Читання завершеного стану видаляє файл, тож друге опитування повертає «немає такого файлу» з прапорцем «не завершено»: клієнт, який опитує на один раз забагато, назавжди бачить «ще працює» для створення, що вдалося. А виклик стану живе лише на поверхні, доступній тільки для admin: ось чому вимога імені admin вище не є необовʼязковою.
Призупинення є трюком вебсервера, а не блокуванням облікового запису
Призупинення й відновлення є добре поводженою частиною цього API: обидва набувають чинності негайно, і власний список панелі одразу показує новий стан.
Але знайте, що воно робить. CyberPanel переписує конфігурацію vhost сайту на сторінку призупинення й перезапускає вебсервер. Unix-користувача не заблоковано; FTP, пошта та бази даних працюють далі. Недоступним стає сайт, і більше нічого. Це відрізняється від DirectAdmin, і це важить у ту мить, коли ви використовуєте призупинення, щоб змусити до оплати.
Ще одне, що варте константи у вашому коді, а не змінної: реалізацією є if state == "Suspend": … else: <resume>, без жодної перевірки значення. Виміряно на реальному сайті:
1. state:"Suspend" → list: Suspended
2. state:"suspend" → {"websiteStatus": 1, "error_message": "None"}
3. list: → Active ← a lowercase letter resumed the siteОдруківка беззвучно повторно активує призупиненого клієнта й повідомляє про успіх.
Зміна пакета змінює облік, і більше нічого
changePackageAPI повертається приблизно за 270 мілісекунд, і панель показує нову назву пакета. Виміряно потім зсередини сервера, з пакетом, що навмисно мав інші ліміти: квота диска не змінилася (soft 0, hard 0), а конфігурація vhost далі несла ліміти памʼяті та процесів старого пакета.
Нічого не було застосовано. Уся операція зводиться до оновлення поля в базі даних. Читайте назву пакета в CyberPanel як облік, а не як ліміт, що переїхав разом із нею, і все, що над панеллю, має сказати про це, а не натякати, що підвищення набуло чинності.
Даних про використання немає
CyberPanel є єдиною панеллю керування в Provibr без графіків використання, і це не упущення в інтеграції: панель цього не вимірює.
Трафік обчислюється, а тоді відкидається: він ніколи не сягає переліку. Використання диска бере значення з кешу, збереженого в записі сайту, а на щойно створеному сайті це поле порожнє, тож повідомлене значення відкочується до нуля. Нуль із порожнього кешу не відрізнити від сайту, який справді нічого не використовує. Графік, що навіки стоїть на нулі, має вигляд вимірювання; ось чому його немає.
Що Provibr із цим робить
Provibr підключається через агента всередині вашої власної мережі, який встановлює вихідне зʼєднання, тож панелі нічого не треба виставляти назовні. Він просить чотири речі: адресу панелі разом із портом 8090, логін admin, пароль цього адміністратора і (доки панель усе ще використовує сертифікат, з яким вона постачалася) відбиток SHA-256 для закріплення.
Останнє на практиці не є необовʼязковим. Кожен свіжий CyberPanel подає той самий самопідписаний сертифікат, виданий на www.example.com і підписаний самим CyberPanel. Браузер називає його хибним, а не самопідписаним, і ланцюжок ніколи не проходить перевірку. Закріпити відбиток означає довіряти саме цьому одному сертифікату замість того, щоб вимикати перевірку. Поставте свій власний сертифікат на імʼя хоста панелі, і ланцюжок перевіриться сам; тоді лишіть поле порожнім.
Усвідомте, що це за пароль. У CyberPanel немає API-токена, що покривав би ці команди: усередині його власного API шлях токена ввімкнено або вимкнено для кожної кінцевої точки, і всі чотири, що створюють, призупиняють, перепаковують і видаляють сайт, вимагають пароля. Тож це повний пароль вашого головного адміністратора.
Коли це на місці: пакети стають продаваними як вебтарифи під вашою власною назвою та ціною, замовлення створюють сайти й чекають на справжній результат, а не на першу відповідь, призупинення й відновлення працюють на вимогу та коли ви перевищуєте потужність, а сайти, що вже існують, можна імпортувати.
Чого воно не робить
Provibr керує сайтами, а не панеллю: він не встановлює CyberPanel, не оновлює його й не змінює налаштування сервера. Консолі немає. DNS, поштові скриньки та бази даних лишаються недоторканими: CyberPanel робить усе це сам, і ніщо над ним ними не керує. І графіків використання немає, бо немає нічого чесного, що можна було б намалювати.
Вам не обовʼязково ставити на одну панель. Provibr сьогодні тримає свої панелі керування, гіпервізори та ігрові панелі пліч-о-пліч, в одному інвентарі, з однією моделлю прав і одним журналом активності.