Як продавати вебхостинг із HestiaCP

HestiaCP є найздоровішою відкритою панеллю керування з наявних. Виміряно на GitHub 21 серпня 2026 року: 4481 зірка, 345 учасників і три випуски за один тиждень. Вона дає вам облікові записи, пакети, DNS, пошту, бази даних і чистий інтерфейс, і коштує вона нічого.

Чого вона вам не дає, так це способу все це продавати. Немає форми замовлення, немає рахунку, немає нагадувань про несплату, немає «цей клієнт перестав платити, вимкніть його». Пошукайте hestiacp billing, і, виміряно того самого дня, найвищими результатами будуть форумні гілки: люди питають, як продавати облікові записи HestiaCP, а інші люди відповідають половиною скрипта.

Ця сторінка розповідає про шар над цим: що API HestiaCP насправді повертає, де воно вас укусить і що має бути правильним, перш ніж ви поставите кнопку «Купити» перед незнайомцем.

Що HestiaCP уже вам дає

Дві речі, і це саме ті дві, що треба.

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

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

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

В API двоє дверей, і одні з них брешуть

POST https://host:8083/api/ приймає два види облікових даних, і те, який ви надсилаєте, вирішує, який шлях коду обробляє ваш запит. Старий шлях бере логін і пароль. Новіший шлях, доступний із HestiaCP 1.6, бере ключ доступу: ідентифікатор із 20 символів і секрет із 40 символів.

Вони поводяться не однаково. Надсилання команди, якої не існує:

Застарілий шлях повідомляє про успіх для команди, яку ніколи не запускали. Причина лежить у власному коді HestiaCP: він виводить OK, коли автентифікація повернула нуль, а команда не дала виводу в stdout. Він ніколи не дивиться на власний код виходу команди й ніколи не встановлює HTTP-статус чи заголовок коду виходу для результату. Будь-яка команда, що тихо зазнає невдачі, повертається як OK.

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

HTTP-статус не є відповіддю; відповіддю є код виходу

HestiaCP згортає близько двадцяти внутрішніх кодів виходу до чотирьох HTTP-статусів. Два наслідки, обидва виміряні:

Успішна зміна повертає 204, а не 200. Кожен v-add-user, v-suspend-user, v-delete-user, v-add-web-domain і v-change-user-package повертається як HTTP 204 з порожнім тілом. Клієнт, який приймає лише 200, відхиляє кожен виклик, що спрацював.

HTTP 401 означає чотири різні речі: хибний секрет (вихід 9), ключ поза своїми правами (10), адреса не дозволена (10) і «цього користувача вже призупинено» (5). Клієнт, який читає 401 як «облікові дані хибні», скаже вам, що ваш ключ протермінувався, тоді як усе, що ви зробили, це двічі призупинили обліковий запис.

Читайте Hestia-Exit-Code. Статус є похідним.

Той, що справді вас покладе

Пʼять відхилених викликів, і HestiaCP банить вашу адресу. Це не ліміт частоти, від якого можна відступити, а fail2ban, налаштований за замовчуванням із maxretry = 5 проти /var/log/hestia/auth.log, і він завершується iptables DROP. Після цього панель не відхиляє ваші виклики, вона перестає на них відповідати: ваш моніторинг показує тайм-аути, і це має вигляд мережевої проблеми.

Люди попадаються саме на тому, що вважається невдалим входом. Не лише хибний секрет: перевірка ключа в HestiaCP пише той самий рядок failed to login, коли ключ використано для команди поза його набором прав. Виміряно, у власному журналі автентифікації панелі:

12:57:52 <key> 84.85.173.142 v-list-users successfully launched
12:57:52 <key> 84.85.173.142 failed to login      ← a command outside the key's scope

З цього випливають три правила, і вони не є необовʼязковими:

1. 01Ніколи не повторюйте автоматично після помилки автентифікації чи прав. Цикл повторів на хибному ключі замикає вас назовні за хвилину, і на той час повідомлення, яке бачить ваш клієнт («панель недосяжна» замість «ключ хибний»), є найгіршим можливим сигналом, бо він указує на не ту проблему.
2. 02Ключ має бути без обмежень і, отже, адміністраторський. Порожні права означають кожну команду, і HestiaCP приймає це лише для користувача root. Вбудований набір прав billing близький до цього, але лишає осторонь v-list-user-packages і v-list-web-domains (дві команди, що читають ваш каталог пакетів і домени облікового запису). З цим набором обидві повертаються порожніми, а обмежений ключ, що звертається до них раз на цикл опитування, банить вас за розкладом.
3. 03Ваш текст помилки має згадувати про це, бо для його очищення потрібен shell на панелі: v-delete-firewall-ban <address> HESTIA.

Порожній означає нікого

Ще одна пастка першого запуску. HestiaCP тримає список адрес, яким дозволено користуватися API, у API_ALLOWED_IP. На свіжій інсталяції цей список порожній, а порожній тут означає нікого, а не всіх. Кожен виклик повертається 401 із IP is not allowed to connect with API, тоді як ваш ключ цілком справний. Це найімовірніша перша відмова всієї інтеграції, і вона заслуговує на власне повідомлення про помилку, а не на загальне «автентифікація не вдалася».

Створення облікового запису потребує двох викликів, і цей розрив реальний

DirectAdmin, cPanel і Virtualmin створюють обліковий запис разом із його доменом одним викликом. HestiaCP так не робить:

v-add-user        USER PASSWORD EMAIL [PACKAGE] [NAME]   → creates the user
v-add-web-domain  USER DOMAIN [IP] [RESTART] [ALIASES]   → attaches the domain

Якщо другий виклик зазнає невдачі (домен уже комусь належить або його формат відхилено), ви лишаєтеся зі справжнім unix-користувачем, з домашнім каталогом, без сайту й з рядком у кожному підрахунку, який ви робите. Виміряно з навмисно недійсним доменом: користувач після цього існував із U_WEB_DOMAINS = 0. Усе, що ви будуєте, має це компенсувати: якщо другий крок провалюється, видаліть користувача й повідомте початкову помилку.

Що Provibr робить з усім цим

Provibr підключається до HestiaCP через агента, який працює всередині вашої власної мережі й встановлює вихідне зʼєднання, тож нічого на панелі не треба виставляти назовні. Ви даєте йому чотири речі: адресу панелі разом із портом 8083, ідентифікатор ключа доступу, секрет і, доки панель усе ще використовує свій самопідписаний сертифікат, відбиток SHA-256 для закріплення. Агент тримає їх у власному сховищі на вашому хості; платформа не може прочитати їх назад.

Далі:

• Пакети стають продаваними. Вебтариф хостингу вказує на один пакет в одній інтеграції, під вашою власною назвою, за вашою власною ціною.
• Пʼять дій, адресованих за логіном: створити з доменом і пакетом, призупинити, відновити, перевести пакет, видалити. Створення з двох викликів компенсується, як описано вище.
• Використання надходить безкоштовно з опитуванням. Кожне читання v-list-users несе DISK_QUOTA, U_DISK, BANDWIDTH і U_BANDWIDTH для кожного облікового запису, усе в мегабайтах, тож ліміти й використання опиняються на сторінці сервера та в графіках без другого виклику, що міг би відставати від першого.
• Облікові записи, що вже існують, можна імпортувати. Агент перелічує те, що є на панелі, а ви позначаєте, які з них стануть серверами в Provibr.

Чого воно не робить

Provibr керує обліковими записами, а не панеллю. Він не встановлює HestiaCP, не оновлює його, не змінює налаштування сервера й не торкається DNS, поштових скриньок чи баз даних: вони лишаються в HestiaCP, де ви та ваші клієнти й далі ними користуєтеся. Для облікового запису хостингу консолі немає, бо немає до чого її приєднувати.

І одне чесне зауваження щодо швидкодії: читання панелі з багатьма обліковими записами коштує один додатковий виклик на обліковий запис, бо в HestiaCP немає команди, що перелічувала б домени кожного облікового запису за раз. Виміряно на 26 облікових записах: послідовно це приблизно 8,5 секунди; паралельно повертається менш ніж за дві. Якщо ви пишете це самі, не робіть цього послідовно: приблизно на 60 облікових записах послідовне опитування починає зіштовхуватися з власним наступним обходом.

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