Cómo vender alojamiento web con CyberPanel

CyberPanel es el panel que los proveedores de alojamiento con OpenLiteSpeed citan más a menudo junto a DirectAdmin. Medido en GitHub el 21 de agosto de 2026: 2007 estrellas, 723 bifurcaciones y 362 incidencias abiertas, con un ritmo de publicación más lento que la mayoría de sus pares.

Tiene una API REST, y todo lo que hace falta para vender alojamiento en ella (crear un sitio, suspenderlo, cambiar su paquete, eliminarlo) forma parte de esa API. Lo que no tiene es nada que decida cuándo hacer esas cosas, y lo que sí tiene es un conjunto de respuestas fáciles de malinterpretar.

Antes de nada: el acceso a la API está desactivado

En un CyberPanel recién instalado la API está apagada, y eso vale también para el administrador principal. Se activa en Users → API Access, para el usuario admin. No hace falta nada más; se inicia sesión con las credenciales que ya se tienen.

Si se deja apagada, cada llamada vuelve como API Access Disabled., se envíe lo que se envíe. La parte que cuesta una tarde es el orden: CyberPanel comprueba ese interruptor antes de comprobar la contraseña, así que con él apagado una contraseña correcta y una incorrecta devuelven el mismo 403. Todo apunta a las credenciales mientras el problema está una casilla más allá.

Una vez activado el interruptor, el contrato que hay debajo es limpio y de verdad útil:

correct password  → HTTP 200  {"verifyConn": 1}
wrong password    → HTTP 401  {"verifyConn": 0, "error_message": "Invalid password."}
unknown user      → HTTP 404  {"error_message": "Administrator not found."}

Tres situaciones, tres acciones distintas para el cliente, y las tres se distinguen.

El administrador tiene que llamarse admin

No es un ajuste, sino una condición, y viene de CyberPanel y no de lo que se construye encima. Una parte de su API está protegida por una comprobación literal del nombre que rechaza a cualquier usuario que no sea admin, y esa parte es precisamente la que enumera los sitios del panel e informa de hasta dónde ha llegado uno en creación.

Ambas son inevitables si se quiere vender alojamiento: hace falta la lista para saber qué existe, y la información de progreso por el motivo que da la sección siguiente. Un administrador renombrado no se puede usar, y todo lo que se construya debería decirlo durante la prueba de conexión, antes de que el primer pedido lo descubra por uno.

Una cuenta es un dominio, no un nombre de usuario

Es la diferencia estructural respecto a DirectAdmin, cPanel y Virtualmin, y cambia la manera de modelar el producto.

El registro de sitio de CyberPanel tiene un campo domain único, y cada comando lo apunta: el borrado toma domainName, la suspensión y el cambio de paquete toman websiteName, y los tres localizan el sitio por su dominio. No hay nombre de usuario al que dirigirse. El usuario unix es generado, no elegido: cinco letras extraídas del dominio más cuatro dígitos aleatorios. Medido para provibr-test-1.example.com: provi7346, con el directorio personal nombrado según el dominio y no según el usuario. Ese nombre no se puede elegir ni predecir, y aparece en exactamente una respuesta de API y en ningún listado.

Una consecuencia que conviene conocer antes de la cuenta número cien: crear un sitio crea también unas credenciales de panel por debajo, con acceso a la API, y esas credenciales sobreviven al borrado del sitio. Medido tras un borrado: usuario unix eliminado, directorio personal eliminado, vhost eliminado, fila en base de datos eliminada, y las credenciales del propietario aún ahí. La ruta de limpieza de CyberPanel está protegida por una comprobación que no puede tener éxito en el momento en que se ejecuta, y el error resultante se traga. Si nada por encima del panel las retira, cada cliente cancelado deja unas credenciales atrás.

Crear un sitio anuncia el éxito antes de saberlo

Esto es lo más importante que entender de la API de CyberPanel.

createWebsite responde en unos tres segundos con:

{"status": 1, "createWebSiteStatus": 1, "error_message": "None",
 "tempStatusPath": "/home/cyberpanel/2424", "LinuxUser": "provi7346"}

Eso llega antes de que se haya hecho la mayor parte del trabajo: el punto de acceso construye una línea de comandos, la lanza sin esperar y devuelve el control. El progreso real vive en un fichero de estado, legible mediante una llamada aparte. Medido, una creación real:

+ 2.8s   10%  Creating DNS records..
+ 4.8s   25%  Setting up directories..
+ 6.9s   70%  Setting up SSL..        ← sits here for 28 seconds
+35.3s   80%  Creating mail child domain..
+49.5s  100%  Website successfully created. [200]

Unos cincuenta segundos, de los cuales unos veintiocho son un intento de SSL que el panel hace se envíe lo que se envíe: la API sobrescribe ese campo sin condiciones, así que no hay manera de crear un sitio sin SSL. En un dominio que aún no resuelve públicamente, eso son veintiocho segundos esperando un certificado que no llegará.

Y la primera respuesta no es un veredicto. Medido con datos deliberadamente erróneos:

Solo se comprueba de inmediato la forma del dominio y del correo. Si el dominio está libre, y si el paquete existe, solo se ve en el fichero de estado. Una integración que se fía de la primera respuesta anunciará un pedido con éxito para un dominio que ya estaba ocupado.

Dos detalles más hacen que sondearlo sea más difícil de lo que parece. Leer un estado completado borra el fichero, así que un segundo sondeo devuelve «no existe el fichero» con una marca de «sin terminar»: un cliente que sondea una vez de más ve «aún trabajando» para siempre, para una creación que tuvo éxito. Y la llamada de estado vive solo en la superficie reservada a admin, razón por la cual el requisito del nombre admin de arriba no es opcional.

La suspensión es un truco del servidor web, no un bloqueo de cuenta

Suspender y reactivar son la parte bien educada de esta API: ambas surten efecto de inmediato, y la propia lista del panel muestra el nuevo estado al instante.

Pero conviene saber qué hace. CyberPanel reescribe la configuración vhost del sitio hacia una página de suspensión y reinicia el servidor web. El usuario unix no queda bloqueado; el FTP, el correo y las bases de datos siguen funcionando. El sitio se vuelve inaccesible, y nada más. Eso difiere de DirectAdmin, y cuenta en cuanto se usa la suspensión para hacer cumplir un pago.

Una cosa más, que merece una constante en el código y no una variable: la implementación es if state == "Suspend": … else: <resume>, sin ninguna validación del valor. Medido en un sitio real:

1. state:"Suspend"  → list: Suspended
2. state:"suspend"  → {"websiteStatus": 1, "error_message": "None"}
3. list:            → Active     ← a lowercase letter resumed the site

Una errata reactiva silenciosamente a un cliente suspendido y anuncia éxito.

Cambiar de paquete cambia la contabilidad, y nada más

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

No se aplicó nada. Toda la operación es una modificación de un campo en base de datos. El nombre de paquete en CyberPanel debe leerse como administración, no como un límite que se hubiera movido con él, y lo que hay por encima del panel debería decirlo en lugar de dar a entender que una mejora surtió efecto.

No hay datos de consumo

CyberPanel es el único panel de control en Provibr sin gráficas de consumo, y no es una omisión de la integración: el panel no lo mide.

El tráfico se calcula y luego se descarta: nunca llega al listado. El uso de disco sale de una caché guardada en el registro del sitio, y en un sitio recién creado ese campo está vacío, así que el valor reportado cae a cero. Un cero salido de una caché vacía no se distingue de un sitio que de verdad no consume nada. Una gráfica que se queda a cero para siempre parece una medición; por eso no hay ninguna.

Lo que Provibr hace con ello

Provibr se conecta mediante un agente dentro de la propia red que marca hacia el exterior, de modo que el panel no necesita exponer nada. Pide cuatro cosas: la dirección del panel incluyendo el puerto 8090, el nombre de usuario admin, la contraseña de ese administrador y, mientras el panel siga usando el certificado con el que vino, la huella SHA-256 que fijar.

Esta última no es opcional en la práctica. Todo CyberPanel recién instalado presenta el mismo certificado autofirmado, emitido a nombre de www.example.com y firmado por el propio CyberPanel. Un navegador lo califica de incorrecto en lugar de autofirmado, y la cadena nunca se valida. Fijar la huella significa confiar en ese único certificado en lugar de desactivar la verificación. Basta con poner un certificado propio en el nombre de host del panel y la cadena se valida sola; entonces se deja el campo vacío.

Conviene saber qué es esa contraseña. CyberPanel no tiene ningún token de API que cubra estos comandos: dentro de su propia API la vía del token está habilitada o deshabilitada por punto de acceso, y los cuatro que crean, suspenden, cambian de paquete y eliminan un sitio exigen todos la contraseña. Así que se trata de la contraseña completa del administrador principal.

Con eso en su sitio: los paquetes se vuelven vendibles como planes web bajo un nombre y un precio propios, los pedidos crean sitios y esperan el resultado real en lugar de la primera respuesta, la suspensión y la reactivación funcionan a demanda y cuando se supera la capacidad, y los sitios que ya existen se pueden importar.

Lo que no hace

Provibr gestiona sitios, no el panel: no instala CyberPanel, no lo actualiza y no cambia ningún ajuste del servidor. No hay consola. El DNS, los buzones y las bases de datos quedan intactos: CyberPanel hace todo eso por sí mismo y nada por encima lo dirige. Y no hay gráficas de consumo, porque no hay nada honesto que dibujar.

No hace falta apostarlo todo a un solo panel. Provibr hace funcionar hoy sus paneles de control, sus hipervisores y sus paneles de juego en paralelo, en un solo inventario, con un solo modelo de permisos y un solo registro de actividad.