Cómo vender alojamiento web con HestiaCP

HestiaCP es el panel de control abierto más saludable que hay. Medido en GitHub el 21 de agosto de 2026: 4481 estrellas, 345 colaboradores y tres versiones publicadas en una sola semana. Ofrece cuentas, paquetes, DNS, correo, bases de datos y una interfaz limpia, y no cuesta nada.

Lo que no ofrece es una manera de vender nada de eso. No hay formulario de pedido, ni factura, ni reclamación de impagos, ni un «este cliente dejó de pagar, hay que cortarlo». Al buscar hestiacp billing, y medido el mismo día, los primeros resultados son hilos de foro: gente que pregunta cómo vender cuentas HestiaCP, y otra gente que responde con medio script.

Esta página trata de la capa de arriba: lo que la API de HestiaCP devuelve de verdad, dónde va a morder, y qué tiene que estar bien antes de poner un botón de Comprar delante de un desconocido.

Lo que HestiaCP ya ofrece

Dos cosas, y son las dos correctas.

Los paquetes. Un paquete HestiaCP describe lo que una cuenta puede usar: espacio en disco, tráfico, y cuántos dominios, bases de datos y buzones. Ese es el catálogo de producto, definido una vez y designado por su nombre desde todo lo demás.

Un ciclo de vida de cuenta que encaja con una suscripción. Crear, suspender, reactivar, mover a otro paquete, eliminar: exactamente los estados que atraviesa una cuenta de alojamiento de pago, y hay un comando para cada uno:

El resto de esta página trata de la distancia entre esa tabla y algo con lo que se pueda contar a las tres de la madrugada.

La API tiene dos puertas, y una de ellas miente

POST https://host:8083/api/ acepta dos clases de credenciales, y la que se envíe decide qué ruta de código atiende la petición. La vía antigua toma un nombre de usuario y una contraseña. La más nueva, disponible desde HestiaCP 1.6, toma una clave de acceso: un identificador de 20 caracteres y un secreto de 40 caracteres.

No se comportan igual. Al enviar un comando que no existe:

La vía heredada anuncia éxito para un comando que nunca se ejecutó. La causa está en el propio código fuente de HestiaCP: emite OK en cuanto la autenticación devolvió cero y el comando no escribió nada en la salida estándar; nunca mira el código de salida del propio comando, y nunca fija un estado HTTP ni la cabecera de código de salida del resultado. Cualquier comando que falla en silencio vuelve como OK.

Así que: usar claves de acceso. No solo porque la vía heredada puede mentir, sino porque una clave se revoca por separado, figura por su nombre en el panel, y no mete la contraseña de administrador del panel en el cofre de otra persona. Tampoco conviene construir un repliegue de una a otra: dos puertas significan dos superficies de error, y aquí la puerta de repliegue es la que no es fiable.

El estado HTTP no es la respuesta: lo es el código de salida

HestiaCP repliega una veintena de códigos de salida internos sobre cuatro estados HTTP. Dos consecuencias, ambas medidas:

Una mutación con éxito devuelve 204, no 200. Cada v-add-user, v-suspend-user, v-delete-user, v-add-web-domain y v-change-user-package vuelve como HTTP 204 con un cuerpo vacío. Un cliente que solo acepta 200 rechaza así cada llamada que funcionó.

HTTP 401 significa cuatro cosas distintas: secreto incorrecto (salida 9), clave fuera de sus permisos (10), dirección no autorizada (10) y «este usuario ya está suspendido» (5). Un cliente que lee 401 como «las credenciales son incorrectas» anunciará que la clave caducó cuando lo único que se hizo fue suspender una cuenta dos veces.

Leer Hestia-Exit-Code. El estado no es más que una derivada.

El que de verdad deja fuera de juego

Cinco llamadas rechazadas y HestiaCP bloquea la dirección. No es un límite de tasa del que se pueda ir retirando: es fail2ban, configurado de origen con maxretry = 5 sobre /var/log/hestia/auth.log, y termina en un DROP de iptables. Después de eso el panel no rechaza las llamadas, deja de responderlas: la supervisión muestra tiempos de espera agotados y parece un problema de red.

Lo que pilla a la gente es qué cuenta como inicio de sesión fallido. No solo un secreto incorrecto: la comprobación de clave de HestiaCP escribe la misma línea failed to login cuando una clave se usa para un comando fuera de su conjunto de permisos. Medido, en el propio registro de autenticación del panel:

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

Tres reglas se derivan, y ninguna es opcional:

1. 01Nunca reintentar automáticamente tras un error de autenticación o de permiso. Un bucle de reintento sobre una clave equivocada deja fuera en menos de un minuto, y para entonces el mensaje que ve el cliente es «panel inaccesible» en lugar de «la clave no sirve»: la peor señal posible, porque apunta al problema equivocado.
2. 02La clave debe carecer de restricción de alcance, y por tanto ser la del administrador. Permisos vacíos significan todos los comandos, y HestiaCP solo lo acepta para el usuario root. El conjunto de permisos billing que viene de serie se acerca, pero deja fuera v-list-user-packages y v-list-web-domains: los dos comandos que leen el catálogo de paquetes y los dominios de una cuenta. Con ese conjunto ambos vuelven vacíos, y una clave restringida que los toca una vez por ciclo de sondeo provoca el bloqueo puntualmente.
3. 03El texto de error tiene que mencionarlo, porque levantar el bloqueo exige una consola en el panel: v-delete-firewall-ban <address> HESTIA.

Vacío significa nadie

Otra trampa del primer intento. HestiaCP mantiene en API_ALLOWED_IP una lista de direcciones autorizadas a usar la API. En una instalación nueva esa lista está vacía, y vacía aquí significa nadie, no todo el mundo. Cada llamada vuelve en 401 con IP is not allowed to connect with API mientras la clave está perfectamente bien. Es el primer fallo más probable de toda la integración, y merece su propio mensaje de error en lugar de un «fallo de autenticación» genérico.

Crear una cuenta cuesta dos llamadas, y ese hueco es real

DirectAdmin, cPanel y Virtualmin crean una cuenta junto con su dominio en una sola llamada. HestiaCP no:

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

Si la segunda llamada falla (el dominio ya pertenece a alguien, o su formato se rechaza), queda un usuario unix real, con un directorio personal, sin sitio, y una fila en cada recuento que se haga. Medido con un dominio deliberadamente inválido: el usuario existía después con U_WEB_DOMAINS = 0. Todo lo que se construya tiene que compensarlo: si el paso dos falla, eliminar el usuario e informar del error original.

Lo que Provibr hace con todo esto

Provibr se conecta a HestiaCP mediante un agente que corre dentro de la propia red y marca hacia el exterior, de modo que no hace falta exponer nada en el panel. Se le dan cuatro cosas: la dirección del panel incluyendo el puerto 8083, el identificador de la clave de acceso, el secreto y, mientras el panel siga usando su certificado autofirmado, la huella SHA-256 que fijar. El agente las guarda en su propio cofre en el host; la plataforma no puede releerlas.

A partir de ahí:

• Los paquetes se vuelven vendibles. Un plan de alojamiento web apunta a un paquete de una integración, bajo un nombre propio, a un precio propio.
• Cinco acciones, dirigidas por el nombre de usuario: crear con un dominio y un paquete, suspender, reactivar, cambiar de paquete, eliminar. La creación en dos llamadas se compensa como se describe arriba.
• El consumo llega gratis con el sondeo. Cada lectura de v-list-users lleva DISK_QUOTA, U_DISK, BANDWIDTH y U_BANDWIDTH para cada cuenta, todo en megabytes, de modo que límites y consumo aterrizan en la página del servidor y en las gráficas sin una segunda llamada que pudiera quedarse por detrás de la primera.
• Las cuentas que ya existen se pueden importar. El agente enumera lo que hay en el panel y se marca cuáles de ellas pasan a ser servidores en Provibr.

Lo que no hace

Provibr gestiona cuentas, no el panel. No instala HestiaCP, no lo actualiza, no cambia ningún ajuste del servidor, y no toca ni el DNS, ni los buzones, ni las bases de datos: todo eso se queda en HestiaCP, donde uno y sus clientes siguen usándolo. No hay consola para una cuenta de alojamiento, porque no hay nada a lo que conectarla.

Y una nota de rendimiento honesta: leer un panel con muchas cuentas cuesta una llamada extra por cuenta, porque HestiaCP no tiene ningún comando que enumere los dominios de todas las cuentas de una vez. Medido sobre 26 cuentas, en serie son unos 8,5 segundos; en paralelo baja de dos. Quien escriba esto por su cuenta, que no lo haga en serie: hacia las 60 cuentas un sondeo en serie empieza a chocar con su propia ronda siguiente.

No hace falta elegir un panel y conformarse con él. Provibr hace funcionar hoy sus paneles de control, sus hipervisores y sus paneles de juego en paralelo, bajo un solo inventario, un solo modelo de permisos y un solo registro de actividad. HestiaCP para los clientes que quieren un panel abierto, otra cosa para los que piden cPanel por su nombre, y un solo lugar donde ver ambos.