Cómo vender alojamiento web con CloudPanel

CloudPanel es el panel que se instala cuando se quiere un sitio funcionando rápido y nada más en medio. Es gratuito, se pone en una instancia cloud nueva en minutos, y lo que sale es una pila NGINX y PHP-FPM sin adornos, con Let's Encrypt, una base de datos y una integración con Cloudflare. Sin servidor de correo. Sin capas que no se pidieron.

Ese enfoque es justo lo que gusta, y también por lo que vender alojamiento con él es un ejercicio distinto que con DirectAdmin o cPanel. CloudPanel gestiona sitios en un servidor. No gestiona clientes que pagan. No son el mismo problema, y de la distancia entre ambos trata esta página.

En torno a qué se construye CloudPanel en realidad

Un servidor, y los sitios que hay en él.

Se crea un sitio (PHP, estático, Node.js, Python o un reverse proxy) y CloudPanel escribe un vhost NGINX, un pool PHP-FPM, un usuario Linux de sitio y un directorio personal. Se pone una base de datos al lado. Se le apunta un certificado. Ese es el bucle, y es bueno: un desarrollador o una agencia que hace funcionar veinte sitios en una máquina obtiene una interfaz limpia sobre exactamente lo que manipula.

Lo que no tiene es la capa por encima de eso: un cliente que posee un conjunto de sitios, con un plan, una cuota y un interruptor. CloudPanel tiene usuarios de panel con roles (administrador, gestor de sitio, usuario) y esos usuarios se pueden restringir a sitios concretos. Pero eso es control de acceso para gente que inicia sesión, no una cuenta comercial que se pueda facturar y cortar.

La distinción suena académica hasta que el primer cliente deja de pagar.

Toda la superficie de control cabe en una sola herramienta de línea de comandos

CloudPanel no tiene API REST. Todo lo que la automatización puede hacer, lo hace mediante clpctl, la propia herramienta de línea de comandos del panel, que corre en el host como root. Se puede automatizar bien (no interactiva, opciones en vez de preguntas) y cubre las partes que cabría esperar:

Dos cosas de esa tabla merecen atención antes de planificar nada a su alrededor.

La primera: la identidad de un sitio es su nombre de dominio. No un identificador numérico, no un nombre de cuenta, sino el dominio. Todo lo que se construye se ancla en él, y tiene que sobrevivir a un cliente que quiere mover un dominio de un plan a otro.

La segunda pesa más, y es de lo que trata la sección siguiente: en esa tabla no hay ningún verbo para apagar un sitio.

Las tres carencias que cuentan al vender

No hay suspensión

clpctl tiene site:add:* y tiene site:delete. Entre medias no tiene nada. No hay site:suspend, ni site:disable, ni un interruptor de mantenimiento, y la interfaz del panel tampoco tiene equivalente.

Para un negocio de alojamiento no es una carencia cosmética, porque «la factura lleva treinta días de retraso» es con diferencia la situación más frecuente sobre la que habrá que actuar, y eliminar el sitio no es la respuesta. Eliminar es irreversible y se lleva los datos del cliente; un cliente que paga el día treinta y uno espera encontrar su sitio donde lo dejó.

Así que cualquier cosa que venda alojamiento CloudPanel tiene que inventar la suspensión. Los candidatos habituales son detener el pool PHP-FPM del sitio, o editar el vhost para que el sitio deje de responder. Ambos funcionan, y el segundo es el mejor de los dos: un pool detenido produce un 502, que para el cliente parece un servidor averiado en lugar de una factura en retraso.

Editar bien un vhost es una lista más corta de lo que parece. Conviene encuadrar lo que se inserta entre un comentario de inicio y uno de fin, para que reactivar signifique borrar exactamente esas líneas y nada más. Hacerlo en cada bloque server público, porque un vhost suele tener uno para el puerto 80 y otro para el 443. Un sitio suspendido por HTTP pero sano por HTTPS es peor que uno no suspendido en absoluto, ya que parece que funcionó. Lanzar nginx -t antes de recargar, porque se trata de un servidor web compartido y una configuración rota se lleva por delante todos los sitios que hay en él. Con esas tres cosas la suspensión se vuelve una acción ordinaria, instantánea y del todo reversible. Provibr hace exactamente esto: un return 403; marcado, cada bloque público, probado antes de recargar.

Lo que ningún montaje arregla es que el panel no lo sabe. CloudPanel no tiene el concepto de sitio suspendido, así que mostrará uno suspendido como ordinario, y cualquiera con acceso al panel o al host puede abrir el fichero y quitar la línea, incluido el cliente que se acaba de suspender. El estado se puede hacer legible (la marca está a un grep de distancia, así es como Provibr detecta una edición manual) pero no se puede hacer que CloudPanel lo asuma como propio.

Decidir qué significa «apagado» antes del primer cliente, no después del primer moroso.

No hay paquetes

CloudPanel no tiene ni planes, ni cuotas, ni límites por sitio. Sin cuota de disco, sin tope de ancho de banda, sin «este sitio puede tener tres bases de datos». Lo más parecido a un paquete es una plantilla de vhost, que es una configuración NGINX: útil, pero no es un límite, y no detendrá a nadie que consuma 400 GB.

Eso significa que el catálogo de producto no puede vivir en el panel. Lo que separa el plan de 5 € del de 15 € debe definirse, aplicarse y medirse en algún lugar por encima de CloudPanel. Si no se aplica en ninguna parte, no es un plan. Es una sugerencia.

No hay lista de sitios

Existe user:list para los accesos del panel. No existe site:list. Los sitios en sí viven en la propia base de datos SQLite del panel, en el host.

Eso importa más de lo que parece, porque una lista es aquello de lo que se hace la conciliación. Sin ella no se puede responder «¿lo que estoy facturando sigue existiendo?», no se puede detectar un sitio que alguien borró a mano, y no se puede importar un servidor existente a nada en absoluto.

La salida es leer esa base de datos directamente: /home/clp/htdocs/app/data/db.sq3, un select sobre la tabla site, y se tiene cada dominio con su usuario, su plantilla y su versión de PHP. Es lo que hace Provibr, y aquello a lo que acaba llegando cualquier cosa seria. Basta saber que se lee un esquema interno y no una interfaz: puede cambiar en una versión sin que eso sea una promesa rota, así que figura en la lista de cosas que revisar de nuevo tras una actualización del panel.

Y una restricción de diseño por debajo de todo esto

clpctl corre como root en el host. No es un detalle de implementación que se pueda sortear: escribe configuración de NGINX, crea usuarios Linux y gestiona servicios del sistema, y eso exige los privilegios que exige.

La consecuencia es que automatizar CloudPanel es una cuestión de privilegios antes que una cuestión de integración. Todo lo que pilota clpctl (el propio script, una tarea cron, una herramienta de despliegue) corre como root en un servidor web de producción que aloja los sitios de otras personas. Sea lo que sea que se construya, hay que construirlo sabiendo que la credencial en juego no es un token de API de alcance limitado; es acceso administrativo a la máquina. Mantenerla estrecha, mantenerla auditable, y mantenerla lejos de todo lo que un cliente pueda alcanzar.

Lo que tiene que existir por encima del panel

Al quitar el detalle propio del panel, la lista es la misma para cualquier panel de control, y ahí está lo útil: no cambia si más adelante se cambia de panel:

• Un formulario de pedido y un catálogo, con planes que signifiquen algo aplicable.
• Un pago que dispara el aprovisionamiento en segundos, no en una jornada laboral.
• Un proceso de reclamación de impagos (vencido, avisado, suspendido, restablecido) con una acción definida en cada paso.
• Una capacidad visible, para saber cuántas cuentas se llevan y lo que cuestan antes de que lo diga la factura.
• Un registro de auditoría, para que «quién borró ese sitio» tenga respuesta.
• Un modelo de permisos para las personas que trabajan con uno, para que el soporte pueda reiniciar algo sin poder borrarlo todo.

Nada de eso viene con CloudPanel, y nada de eso es lo que CloudPanel intenta ser.

Dónde encaja Provibr

La compatibilidad con CloudPanel ya funciona. Un agente dentro de la propia red se conecta al host por SSH y ejecuta clpctl igual que se haría a mano, así que no se instala nada en el panel y ningún puerto tiene que dar la cara a internet. Crear un sitio, suspenderlo, reanudarlo y eliminarlo funciona, y los sitios que ya estaban solo se importan si se marcan. Alrededor está la capa descrita arriba: planes y capacidad, un precio por unidad, un modelo de permisos, un registro de actividad, y una API REST y un módulo WHMCS para pilotarlo desde aquello con lo que ya se factura.

Lo que la integración no puede hacer es borrar las carencias de arriba, porque son propiedades del panel. La suspensión es la parte inventada: una regla de NGINX marcada que devuelve 403, insertada en cada bloque de servidor público y comprobada antes de recargar; al reanudar se retira y el sitio vuelve byte a byte. La plantilla de vhost queda fija en cuanto el sitio existe, así que no hay cambio de paquete: pasar a otra plantilla o a otra versión de PHP significa volver a crearlo, y Provibr lo dice en lugar de fingir que hubo un cambio. Tampoco hay consola ni gráfica de consumo, porque CloudPanel no mide ninguna de las dos.

Lo que no hará

Mejor decirlo ahora que más tarde: gestionar cuentas no es gestionar el panel. Instalar CloudPanel, actualizarlo, cambiar ajustes del servidor, afinar NGINX, y ocuparse de las bases de datos y los certificados que crean los clientes: eso se queda del lado de uno, en el panel, donde le corresponde.

No hace falta jugarse el negocio a un solo panel. Provibr hace funcionar en paralelo sus paneles de control, sus hipervisores y sus paneles de juego, bajo un solo inventario, un solo modelo de permisos y un solo registro de actividad. Un panel NGINX ligero para los clientes que quieren velocidad en una sola máquina, algo con un árbol de revendedores para los que piden cPanel por su nombre, y un solo lugar donde ver ambos.