El módulo WHMCS para CyberPanel, y la alternativa

Si se ejecuta WHMCS y se quiere vender alojamiento OpenLiteSpeed, se sale a buscar un módulo de aprovisionamiento para CyberPanel. Medido el 21 de agosto de 2026, los resultados de esa búsqueda son un repositorio de GitHub mantenido por una sola persona, y un hilo de un foro comunitario.

No es una crítica al trabajo de nadie. Es la descripción de un vacío: un software que se sitúa entre las facturas y los sitios web de los clientes, y que la mayoría de los hosters encuentra en forma de proyecto paralelo y no de producto.

Esta página trata de lo que un módulo así puede hacer, de lo que estructuralmente no puede, y del aspecto de otra forma de solución. La primera parte es la que más pesa, porque el techo no es el módulo, es la API de CyberPanel.

El techo: lo que permite la API de CyberPanel

Medido contra CyberPanel 3.0, no tomado de la documentación. Cualquier módulo (el de GitHub, uno escrito por uno mismo, o el que se describe más abajo) queda limitado por todo lo que sigue.

Crear un sitio responde antes de conocer el resultado

createWebsite responde en unos tres segundos con createWebSiteStatus: 1. No es un veredicto; significa que el trabajo ha comenzado. El endpoint lanza un comando en segundo plano y responde de inmediato. El progreso real vive en un archivo de estado que hay que sondear por separado.

Medido con datos deliberadamente incorrectos:

Solo se valida por adelantado la forma del dominio y del correo. Un módulo que se fía de la primera respuesta marcará un pedido de WHMCS como activo para un sitio que nunca se creó, y el cliente recibe credenciales de bienvenida para algo que no existe.

Sondear ese archivo de estado tiene dos trampas más. Leer un estado completado lo elimina, de modo que un sondeo de más convierte una creación terminada en un «en curso» permanente. Y la llamada de estado se apoya en la parte de la API de CyberPanel que rechaza a todo administrador que no se llame literalmente admin.

La creación completa dura unos cincuenta segundos, de los cuales unos veintiocho son un intento de SSL que CyberPanel realiza sin condiciones: la API sobrescribe ese campo se envíe lo que se envíe. Cualquier módulo necesita un tiempo de espera que lo tenga en cuenta.

Cambiar de paquete cambia un campo en base de datos

changePackageAPI responde en unos 270 milisegundos y el panel muestra el nombre nuevo. Medido después desde dentro del servidor, con un paquete que llevaba otros límites: la cuota de disco no había cambiado (soft 0, hard 0) y la configuración del vhost seguía llevando los límites de memoria y de procesos del paquete antiguo.

No se aplicó nada. Así, un pedido de mejora de WHMCS puede completarse, facturarse y cambiar el nombre en el panel mientras los límites reales del cliente son exactamente los de antes. Ningún módulo puede corregir esto: toda la implementación de ese endpoint es una modificación de campo.

La suspensión no bloquea la cuenta

CyberPanel suspende un sitio reescribiendo su vhost hacia una página de suspensión y reiniciando el servidor web. El usuario unix no queda bloqueado; el FTP, el correo y las bases de datos siguen funcionando. Al suspender por impago, el cliente sigue teniendo su correo y su base de datos. Puede ser exactamente lo que se busca, pero debería ser una decisión y no una sorpresa.

Hay también un filo más afilado: la implementación es if state == "Suspend": … else: <resume>, sin validación. Medido: enviar "suspend" en minúsculas reactivó un sitio suspendido y anunció un éxito. Cualquier módulo debería mantener esos dos valores como constantes y nunca componerlos a partir de una variable.

No hay datos de consumo

El tráfico lo calcula CyberPanel y luego se descarta antes de llegar a lista alguna. El consumo de disco procede de una caché en el registro del sitio web, vacía en un sitio nuevo, así que el valor retrocede a cero, y un cero salido de una caché vacía no se distingue de un sitio que no consume nada.

WHMCS dispone de un hook de recopilación de consumo que espera cifras de disco y de tráfico. En CyberPanel no hay nada honesto que poner en él: un módulo que lo rellena de todos modos comunica un valor por defecto, no una medición.

El acceso a la API está desactivado, y el orden de las comprobaciones oculta por qué

En un CyberPanel nuevo la API está desactivada, incluso para el administrador principal, y el indicador se comprueba antes que la contraseña: con él apagado, una contraseña correcta y una incorrecta devuelven el mismo API Access Disabled. El primer fallo de todo módulo para este panel parece un problema de credenciales y no lo es.

Lo que eso significa para un módulo

Nada de lo anterior es reparable dentro de un módulo WHMCS, porque nada de ello es un problema de módulo. Lo que difiere de un módulo a otro es la honestidad con que lo tratan:

• ¿Sondea el estado de la creación, o se fía de la primera respuesta?
• ¿Lee el estado una vez y registra el resultado, o sondea hasta borrar ese resultado por accidente?
• ¿Avisa de que un cambio de paquete no aplicó nada?
• ¿Deja vacío el hook de consumo, o lo rellena de ceros que parecen datos?
• ¿Dice «el acceso a la API está desactivado» en lugar de «credenciales no válidas»?

Esas son las preguntas que hay que hacerle a cualquier módulo que se esté valorando. Se responden leyendo el código, y pesan más que la lista de funciones. Hay una más, que atañe a uno mismo y no al código: ¿quién lo mantendrá dentro de dieciocho meses? Un módulo de aprovisionamiento se encuentra en el camino crítico de cada pedido que se acepta.

La alternativa: una capa de aprovisionamiento, no un módulo de panel

Provibr se sitúa entre el sistema de facturación y la infraestructura. No es un módulo WHMCS para CyberPanel; es una plataforma de aprovisionamiento que habla con CyberPanel, y con la que WHMCS habla a través de un solo módulo, sea cual sea lo que hay debajo.

La diferencia práctica:

Dos filas merecen un desarrollo, porque son las honestas.

El coste. El módulo es gratis y Provibr no. Provibr cobra por la capacidad reservada (cuántas cuentas de alojamiento se pueden ejecutar a la vez) a un precio unitario escalonado que baja a medida que sube el número. Lo que se cobra a los propios clientes queda íntegramente para uno mismo. Con doce sitios CyberPanel y sin planes de crecer, un módulo gratuito es la respuesta correcta.

Los mismos límites, otra honestidad. Provibr no repara el cambio de paquete de CyberPanel, no inventa cifras de consumo y no bloquea una cuenta suspendida. No puede: son propiedades del panel. Lo que hace es negarse a fingir lo contrario.

Cómo encaja en WHMCS

Un módulo, instalado como un simple zip en modules/servers/. En WHMCS se añade un servidor que apunta a Provibr con una clave de API, y después se hace apuntar un producto de WHMCS a un plan web de Provibr. Un pedido pagado crea la cuenta, una suspensión la suspende, una cancelación la elimina. El cliente conserva una cuenta, una factura y un inicio de sesión.

La clave de API lleva ámbitos, y lo que realmente puede hacer es la intersección de esos ámbitos y los permisos del miembro al que pertenece: así, una clave solo puede restringir el acceso, nunca ampliarlo. Al retirar un permiso a un compañero, cada una de sus claves se estrecha en la siguiente petición, sin que nadie revoque nada.

Si no se ejecuta WHMCS, las mismas operaciones están disponibles a través de la API REST: una clave, una URL base. Todo lo que toca una máquina responde «aceptado» con un comando que seguir, porque la infraestructura solo es accesible a través del agente que está dentro de la red propia. Las lecturas responden de inmediato.

Cuándo el módulo es la mejor opción

Con franqueza: si CyberPanel es el único panel que se ejecuta, ya se dispone de WHMCS, el volumen es pequeño y no cuesta leer PHP cuando algo se rompe, entonces un módulo es menos maquinaria y ningún coste mensual. Los límites de la parte superior de esta página se aplican por igual a ambas opciones.

El argumento a favor de una capa por encima empieza en cuanto se ejecuta más de un panel, en cuanto se quieren sacar las credenciales del host de WHMCS, en cuanto algo que no es WHMCS tiene que hacer pedidos, o en cuanto se quiere que el camino de aprovisionamiento sea el producto de alguien y no el fin de semana de alguien.

Provibr ejecuta hoy sus paneles de control, sus hipervisores y sus paneles de juego en paralelo, en un solo inventario, bajo un solo modelo de permisos, con un solo registro de actividad. No hay por qué elegir entre CyberPanel y todo lo demás.