Модуль CyberPanel для WHMCS та альтернатива

Якщо ви користуєтеся WHMCS і хочете продавати хостинг на OpenLiteSpeed, ви йдете шукати модуль провізіювання для CyberPanel. Виміряно 21 серпня 2026: цей пошук дає репозиторій на GitHub, який підтримує одна людина, і гілку на форумі спільноти.

Це не критика чиєїсь роботи. Це опис прогалини: частина програмного забезпечення, що сидить між вашими рахунками й вебсайтами ваших клієнтів і яку більшість хостерів знаходять як побічний проєкт, а не як продукт.

Ця сторінка про те, що такий модуль може, чого він структурно не може, і який вигляд має інша форма рішення. Перша частина найважливіша, бо стелю задає не модуль, а API CyberPanel.

Стеля: що дозволяє API CyberPanel

Виміряно на CyberPanel 3.0, а не прочитано з документації. Будь-який модуль (той, що на GitHub, той, що ви напишете самі, чи той, що описано далі) обмежений усіма ними.

Створення сайту відповідає, ще не знаючи результату

createWebsite повертається приблизно за три секунди з createWebSiteStatus: 1. Це не вирок; це означає, що роботу розпочато. Кінцева точка запускає фонову команду й повертається одразу. Справжній поступ живе у файлі стану, який доводиться опитувати окремо.

Виміряно з навмисно хибними даними:

Одразу перевіряється лише форма домену та email. Модуль, який вірить першій відповіді, позначить замовлення WHMCS активним для сайту, який ніколи не було створено, а клієнт отримає вітальні облікові дані для чогось, чого не існує.

Опитування цього файлу стану має ще дві пастки. Читання завершеного стану видаляє його, тож одне зайве опитування перетворює завершене створення на вічне «ще працює». А виклик стану сидить на тій частині API CyberPanel, яка відмовляє кожному адміністратору, крім того, що буквально названий admin.

Усе створення триває близько пʼятдесяти секунд, з яких приблизно двадцять вісім припадає на спробу SSL, яку CyberPanel робить безумовно: API перекриває цей прапорець, хоч би що ви надіслали. Будь-якому модулю потрібен таймаут, який це вміщує.

Зміна пакета змінює поле в базі даних

changePackageAPI повертається приблизно за 270 мілісекунд, і панель показує нову назву. Виміряно потім зсередини сервера, з пакетом, що несе інші ліміти: квота диска не змінилася (soft 0, hard 0), а конфігурація vhost далі несла ліміти памʼяті та процесів старого пакета.

Нічого не було застосовано. Тож замовлення на підвищення у WHMCS може завершитися, виставити рахунок і змінити назву в панелі, тоді як реальні ліміти клієнта лишаються рівно тими, що були. Жоден модуль не може це виправити: уся реалізація кінцевої точки зводиться до оновлення поля.

Призупинення не блокує обліковий запис

CyberPanel призупиняє сайт, переписуючи його vhost на сторінку призупинення й перезапускаючи вебсервер. Unix-користувача не заблоковано; FTP, пошта та бази даних працюють далі. Якщо ви призупиняєте за несплату, у клієнта досі є його пошта й база даних. Це може бути саме те, чого ви хочете, але це має бути рішення, а не несподіванка.

Є ще й гостріший край: реалізацією є if state == "Suspend": … else: <resume>, без жодної перевірки. Виміряно: надсилання "suspend" малими літерами повторно активувало призупинений сайт і повідомило про успіх. Будь-який модуль має тримати ці два значення як константи, а не збирати їх зі змінної.

Даних про використання немає

Трафік обчислюється CyberPanel, а тоді відкидається, перш ніж сягне будь-якого переліку. Використання диска бере значення з кешу в записі сайту, який на новому сайті порожній, тож повідомлене значення відкочується до нуля, а нуль із порожнього кешу не відрізнити від сайту, який нічого не використовує.

У WHMCS є гачок збору використання, який очікує цифри диска й трафіку. У CyberPanel немає нічого чесного, щоб туди покласти: модуль, який усе одно його заповнює, повідомляє значення за замовчуванням, а не вимірювання.

Доступ до API вимкнено, а порядок перевірок ховає причину

На свіжому CyberPanel API вимкнено, зокрема для головного адміністратора, і прапорець перевіряється перед паролем, тож із вимкненим прапорцем правильний і неправильний паролі повертають однаковий API Access Disabled. Перша невдача кожного модуля для цієї панелі має вигляд проблеми з обліковими даними, а насправді нею не є.

Що це означає для модуля

Ніщо з вищезгаданого не можна виправити всередині модуля WHMCS, бо ніщо з цього не є проблемою модуля. Між модулями відрізняється лише те, наскільки чесно вони з цим поводяться:

• Чи опитує він статус створення, чи вірить першій відповіді?
• Чи читає він статус один раз і фіксує результат, чи опитує, доки випадково не видалить результат?
• Чи каже він вам, що зміна пакета нічого не застосувала?
• Чи лишає він гачок використання порожнім, чи заповнює його нулями, схожими на дані?
• Чи каже він «доступ до API вимкнено» замість «недійсні облікові дані»?

Це питання, які варто поставити будь-якому модулю, який ви розглядаєте. На них можна відповісти, прочитавши код, і вони важать більше, ніж перелік функцій. Є ще одне, про вас, а не про код: хто підтримуватиме його через вісімнадцять місяців? Модуль провізіювання стоїть на критичному шляху кожного замовлення, яке ви приймаєте.

Альтернатива: шар провізіювання, а не модуль панелі

Provibr сидить між вашою системою білінгу та вашою інфраструктурою. Це не модуль WHMCS для CyberPanel; це платформа провізіювання, яка спілкується з CyberPanel і з якою WHMCS розмовляє через один модуль незалежно від того, що лежить під ним.

Практична відмінність:

Два рядки заслуговують на розширення, бо вони чесні.

Вартість. Модуль безкоштовний, а Provibr платний. Provibr бере плату за потужність, яку ви резервуєте (скільки хостингових облікових записів вам дозволено запускати одночасно), за ціною за одиницю з рівнями, що падає зі зростанням кількості. Те, що ви берете з власних клієнтів, лишається цілком вашим. Якщо у вас дванадцять сайтів CyberPanel і жодних планів рости, безкоштовний модуль є правильною відповіддю.

Ті самі межі, інша чесність. Provibr не лагодить зміну пакета CyberPanel, не вигадує цифри використання й не блокує призупинений обліковий запис. Він не може: це властивості панелі. Він робить лише одне: відмовляється вдавати протилежне.

Як це вписується у WHMCS

Один модуль, встановлений як звичайний zip у modules/servers/. У WHMCS ви додаєте сервер, що вказує на Provibr, з API-ключем, потім вказуєте одному продукту WHMCS один вебплан Provibr. Оплачене замовлення створює обліковий запис, призупинення призупиняє його, припинення видаляє його. Ваш клієнт має один обліковий запис, один рахунок і один вхід.

API-ключ несе області дії, і те, що він насправді може, є перетином цих областей і дозволів учасника, якому він належить, тож ключ може лише звужувати доступ, ніколи не розширювати. Заберіть дозвіл у колеги, і кожен його ключ звузиться при наступному запиті, без того, щоб хтось щось відкликав.

Якщо ви не користуєтеся WHMCS, ті самі операції доступні через REST API: один ключ, одна базова URL. Усе, що торкається машини, відповідає «прийнято» з командою, за якою треба стежити, бо ваша інфраструктура досяжна лише через агента всередині вашої власної мережі. Читання відповідають одразу.

Коли модуль є кращим вибором

Прямо про це: якщо CyberPanel є єдиною панеллю, яку ви запускаєте, у вас уже є WHMCS, ваш обсяг малий і вам зручно читати PHP, коли щось ламається, то модуль дає менше механізмів і жодної щомісячної плати. Межі вгорі цієї сторінки застосовні до обох варіантів однаково.

Аргумент на користь шару над ним починається тоді, коли ви запускаєте більше ніж одну панель, коли ви хочете, щоб облікові дані були поза вашим хостом WHMCS, коли щось інше, ніж WHMCS, має розміщувати замовлення, або коли ви хочете, щоб шлях провізіювання був чиїмось продуктом, а не чиїмись вихідними.

Provibr сьогодні тримає свої панелі керування, гіпервізори та ігрові панелі пліч-о-пліч, в одному інвентарі, з однією моделлю прав, з одним журналом активності. Вам не доведеться вибирати між CyberPanel і всім іншим.