Cum să vindeți găzduire web cu HestiaCP

HestiaCP este cel mai viguros panou de control liber din jur. Măsurat pe GitHub la 21 august 2026: 4.481 de stele, 345 de contribuitori și trei lansări într-o singură săptămână. Vă oferă conturi, pachete, DNS, e-mail, baze de date și o interfață curată, și nu costă nimic.

Ce nu vă oferă este o modalitate de a vinde ceva din toate acestea. Nu există formular de comandă, nici factură, nici somații de plată, nici un „acest client nu mai plătește, dezactivați-l”. Căutați hestiacp billing și, măsurat în aceeași zi, primele rezultate sunt fire de forum: oameni care întreabă cum să vândă conturi HestiaCP și alți oameni care răspund cu jumătate de script.

Această pagină este despre stratul de deasupra: ce returnează cu adevărat API-ul HestiaCP, unde vă va mușca și ce trebuie să fie corect înainte de a putea pune un buton Cumpără în fața unui necunoscut.

Ce vă oferă deja HestiaCP

Două lucruri, și sunt exact cele două care trebuie.

Pachetele. Un pachet HestiaCP descrie ce poate folosi un cont: spațiu pe disc, trafic și câte domenii, baze de date și căsuțe de e-mail. Acesta este catalogul dumneavoastră de produse, definit o singură dată și desemnat de peste tot prin nume.

Un ciclu de viață al contului care se suprapune peste un abonament. A crea, a suspenda, a relua, a muta la alt pachet, a șterge. Acestea sunt exact stările prin care trece un cont de găzduire plătit, și există câte o comandă pentru fiecare:

Restul acestei pagini este despre distanța dintre acest tabel și ceva pe care vă puteți baza la trei dimineața.

API-ul are două uși, iar una dintre ele minte

POST https://host:8083/api/ acceptă două tipuri de date de autentificare, iar cel pe care îl trimiteți decide ce cale de cod tratează cererea dumneavoastră. Calea veche preia un nume de utilizator și o parolă. Cea mai nouă, disponibilă din HestiaCP 1.6, preia o cheie de acces: un identificator de 20 de caractere și un secret de 40 de caractere.

Nu se comportă la fel. Trimițând o comandă care nu există:

Calea moștenită raportează succes pentru o comandă care nu a rulat niciodată. Cauza se află chiar în sursa HestiaCP: afișează OK de îndată ce autentificarea a returnat zero și comanda nu a scris nimic pe ieșirea standard. Nu se uită niciodată la codul de ieșire al comenzii însăși și nu setează niciodată un status HTTP sau antetul cu codul de ieșire pentru rezultat. Orice comandă care eșuează în tăcere revine cu OK.

Așadar: folosiți chei de acces. Nu doar pentru că poate minți calea moștenită, ci pentru că o cheie se poate revoca separat, figurează în panou după nume și nu pune parola de administrator a panoului dumneavoastră în seiful altcuiva. Și nu construiți nici o cale de rezervă de la una la cealaltă: două uși înseamnă două suprafețe de eroare, iar aici ușa de rezervă este cea nesigură.

Statusul HTTP nu este răspunsul: codul de ieșire este

HestiaCP pliază aproximativ douăzeci de coduri de ieșire interne pe patru statusuri HTTP. Două consecințe, ambele măsurate:

O mutație reușită returnează 204, nu 200. Fiecare v-add-user, v-suspend-user, v-delete-user, v-add-web-domain și v-change-user-package a revenit cu HTTP 204 și un corp gol. Un client care acceptă doar 200 respinge fiecare apel care a funcționat.

HTTP 401 înseamnă aici patru lucruri diferite: secret greșit (ieșire 9), cheie în afara permisiunilor sale (10), adresă neautorizată (10) și „acest utilizator este deja suspendat” (5). Un client care citește 401 ca „date de autentificare greșite” vă va anunța o cheie expirată, când de fapt nu ați făcut decât să suspendați un cont de două ori.

Citiți Hestia-Exit-Code. Statusul este doar o derivată.

Cel care chiar vă va pune la pământ

Cinci apeluri refuzate și HestiaCP vă interzice adresa. Aceasta nu este o limită de debit din care vă puteți retrage. Este fail2ban, configurat implicit cu maxretry = 5 pe /var/log/hestia/auth.log, și se termină cu un DROP iptables. După aceea panoul nu vă mai refuză apelurile, ci încetează să le mai răspundă: monitorizarea dumneavoastră arată timpi de așteptare depășiți și pare o problemă de rețea.

Ce prinde oamenii pe picior greșit este ce anume se consideră o autentificare eșuată. Nu doar un secret greșit: verificarea cheii din HestiaCP scrie aceeași linie failed to login atunci când o cheie este folosită pentru o comandă în afara setului său de permisiuni. Măsurat, în chiar jurnalul de autentificare al panoului:

12:57:52 <key> 84.85.173.142 v-list-users successfully launched
12:57:52 <key> 84.85.173.142 failed to login      ← o comandă în afara permisiunilor cheii

Trei reguli decurg de aici, și niciuna nu este opțională:

1. 01Nu reîncercați niciodată automat după o eroare de autentificare sau de permisiune. O buclă de reîncercare pe o cheie greșită vă blochează afară în mai puțin de un minut, iar până atunci mesajul pe care îl vede clientul dumneavoastră este „panou inaccesibil” în loc de „cheia este greșită”, cel mai prost semnal posibil, pentru că indică problema greșită.
2. 02Cheia trebuie să fie fără restricții de domeniu, deci cea a administratorului. Permisiuni goale înseamnă toate comenzile, iar HestiaCP acceptă asta doar pentru utilizatorul root. Setul de permisiuni billing livrat din fabrică se apropie, dar lasă pe dinafară v-list-user-packages și v-list-web-domains, cele două comenzi care citesc catalogul dumneavoastră de pachete și domeniile unui cont. Cu acel set, ambele revin goale, iar o cheie restricționată care le atinge o dată pe ciclu de sondare vă interzice adresa exact cum era de așteptat.
3. 03Textul dumneavoastră de eroare trebuie să menționeze asta, pentru că anularea interdicției necesită un terminal pe panou: v-delete-firewall-ban <adresă> HESTIA.

Gol înseamnă nimeni

Încă o capcană la prima rulare. HestiaCP păstrează în API_ALLOWED_IP o listă a adreselor autorizate să folosească API-ul. Pe o instalare proaspătă, acea listă este goală, iar gol înseamnă aici nimeni, nu toată lumea. Fiecare apel revine cu 401 și IP is not allowed to connect with API, în timp ce cheia dumneavoastră este perfect în regulă. Aceasta este cea mai probabilă primă eroare a întregii integrări și merită propriul mesaj de eroare, nu un „autentificare eșuată” generic.

Crearea unui cont necesită două apeluri, iar acea distanță este reală

DirectAdmin, cPanel și Virtualmin creează un cont împreună cu domeniul său într-un singur apel. HestiaCP nu:

v-add-user        USER PASSWORD EMAIL [PACKAGE] [NAME]   → creează utilizatorul
v-add-web-domain  USER DOMAIN [IP] [RESTART] [ALIASES]   → atașează domeniul

Dacă al doilea apel eșuează (domeniul aparține deja cuiva sau formatul său este respins), rămâneți cu un utilizator unix real, cu un director personal, fără site și cu un rând în fiecare numărătoare pe care o faceți. Măsurat cu un domeniu invalid în mod intenționat: utilizatorul exista după aceea cu U_WEB_DOMAINS = 0. Orice construiți trebuie să compenseze: dacă al doilea pas eșuează, ștergeți utilizatorul și raportați eroarea originală.

Ce face Provibr cu toate acestea

Provibr se conectează la HestiaCP printr-un agent care rulează în propria dumneavoastră rețea și inițiază conexiunea spre exterior, așa că nimic pe panou nu trebuie expus. Îi dați patru lucruri: adresa panoului, inclusiv portul 8083, identificatorul cheii de acces, secretul și, atâta timp cât panoul încă folosește certificatul său autosemnat, amprenta SHA-256 de fixat. Agentul le păstrează în propriul seif pe gazda dumneavoastră; platforma nu le poate citi înapoi.

De acolo:

• Pachetele devin vandabile. Un plan de găzduire web indică un pachet dintr-o integrare, sub un nume al dumneavoastră, la un preț al dumneavoastră.
• Cinci acțiuni, adresate prin numele de utilizator: a crea cu un domeniu și un pachet, a suspenda, a relua, a muta pachetul, a șterge. Crearea în două apeluri este compensată așa cum s-a descris mai sus.
• Consumul vine gratuit odată cu sondarea. Fiecare citire a v-list-users poartă DISK_QUOTA, U_DISK, BANDWIDTH și U_BANDWIDTH pentru fiecare cont, totul în megaocteți, așa că limitele și consumul ajung pe pagina serverului și în grafice fără un al doilea apel care ar putea rămâne în urma primului.
• Conturile care există deja pot fi importate. Agentul enumeră ce se află pe panou, iar dumneavoastră bifați care dintre ele devin servere în Provibr.

Ce nu face

Provibr gestionează conturi, nu panoul. Nu instalează HestiaCP, nu îl actualizează, nu modifică setările serverului și nu atinge DNS-ul, căsuțele de e-mail sau bazele de date; acestea rămân în HestiaCP, unde dumneavoastră și clienții dumneavoastră continuați să le folosiți. Nu există consolă pentru un cont de găzduire, pentru că nu există nimic la care să o atașați.

Și o notă de performanță onestă: citirea unui panou cu multe conturi costă un apel suplimentar per cont, pentru că HestiaCP nu are nicio comandă care să enumere domeniile tuturor conturilor dintr-odată. Măsurat pe 26 de conturi, în serie asta înseamnă aproximativ 8,5 secunde; în paralel revine sub două. Dacă scrieți asta singur, nu o faceți în serie. În jur de 60 de conturi, o sondare în serie începe să se ciocnească de propria rundă următoare.

Nu trebuie să alegeți un singur panou și să vă mulțumiți cu el. Provibr rulează astăzi panourile sale de control, hipervizoarele și panourile de joc unele lângă altele, sub un singur inventar, un singur model de permisiuni și un singur jurnal de activitate. HestiaCP pentru clienții care vor un panou deschis, altceva pentru cei care cer cPanel pe nume, și un singur loc din care le vedeți pe ambele.