Mi ruta de publicación en producción ya está bastante definida: el código entra en GitHub, un workflow protegido decide cuándo publicar y el Self-hosted Runner ejecuta en el servidor únicamente pasos revisados. Cuando vi PanelAlpha Engine en Show HN, no me interesaba tanto si la IA podía ayudar a desplegar. Quería entender qué relación tendría un plano de control MCP para todo el ciclo de vida de una aplicación con mi Runner actual.

Probé PanelAlpha Engine v2.1.1 en un VPS independiente con Ubuntu 24.04.2. En el momento de la QA del artículo, seguía siendo la última versión de GitHub. En una máquina de 1 vCPU, 1,9 GiB de RAM y 50 GB de disco, la instalación llevaba más de dos horas en la fase del Engine. El último progreso registrado era del 70 %, y decidí detener el experimento.

Eso no demuestra que PanelAlpha no se pueda instalar. Lo que mostró es que no es un ejecutor ligero de comandos de IA: es un Hosting Control Plane que interviene en Docker, redes, cortafuegos, aislamiento de proyectos, copias de seguridad y monitorización. Incluso sin completar la instalación obtuve suficientes datos para reconsiderar si sustituir el Runner era la pregunta adecuada.

Un VPS limpio, no el Runner de producción

Antes de empezar no había Docker; docker version devolvía el código 127. Tampoco estaban disponibles iptables ni nft, y los puertos en escucha correspondían prácticamente solo a SSH y chrony. Esa referencia inicial permite atribuir los cambios posteriores de Docker y del cortafuegos a la instalación, sin confundirlos con una configuración anterior.

La propia documentación de instalación recomienda un VPS Debian o Ubuntu nuevo y dedicado. El código del instalador incluye lógica para systemd-resolved, /etc/resolv.conf, las redes Docker y el cortafuegos del host. Por eso no lo ejecuté en el Runner del blog ni en otra máquina de producción.

Primero descargué el bootstrap como archivo y calculé su SHA-256, en lugar de ejecutarlo directamente con curl | sh:

$ curl -fsSL https://get.panelalpha.com/engine -o panelalpha-installer.sh
$ sha256sum panelalpha-installer.sh
5d3c436269e09f8a813073691f61ad18329c0b87a818cb7fc3481344ac8e2496

Después fijé la versión de la prueba:

$ bash /root/panelalpha-installer.sh --engine-version v2.1.1 --no-tui

El primer intento terminó pronto. Faltaba Git y el instalador trató de añadirlo, pero una dependencia no estaba disponible. Este fue el registro real:

git : Depends: liberror-perl but it is not installable
E: Unable to correct problems, you have held broken packages.
[ERROR] Failed to install git (required to fetch the installer).

Ese intento salió con código 1. No lo clasifiqué como un fallo de instalación del núcleo de PanelAlpha: todavía estaba preparando dependencias del host. Los intentos siguientes entraron en una actualización considerable de paquetes del sistema; uno terminó con código 141. Al continuar, la instalación del Engine llegó finalmente a las fases de imágenes, red y cortafuegos.

Hubo un detalle que corrigió mi expectativa inicial. Aunque el código contiene rutas que modifican systemd-resolved y resolv.conf, este VPS no tenía systemd-resolved.service desde el principio y su archivo resolver ya usaba DNS externos. No observé cambios en ese archivo antes y después de la ejecución. La capacidad que existe en el código y lo que ocurrió en esta máquina son pruebas distintas.

Se quedó en el 70 %, pero el host ya había cambiado

Recogí otra instantánea del host antes de terminar. Docker Engine estaba instalado, en la versión 29.8.2, mientras el archivo de progreso de PanelAlpha seguía indicando:

step: Installing PanelAlpha engine
progress: 70

docker ps -a estaba vacío. Describir esto como diez contenedores en segundo plano funcionando habría sido incorrecto. Sí confirmé seis imágenes de PanelAlpha: composer, DNS proxy, Exim, metrics, Pure-FTPd y SFTP. Para la mayor, composer, Docker informaba de 795 MB de disk usage.

Los cambios en la red eran más evidentes. Al principio faltaban iptables y nft; después aparecieron reglas UFW / Docker y cadenas como PA-BUILD-EGRESS, PA-PUBLISHED, PA-TENANT-INPUT y PA-TENANT-NET. Sin embargo, los puertos en escucha seguían siendo solo SSH y chrony. El Engine todavía no estaba preparado para atender peticiones externas.

Al finalizar, el contador RX acumulado de eth1 era de 1,508,426,817 bytes. No lo convertiría en «PanelAlpha descargó 1,5 GB»: la instantánea inicial no incluía RX, así que no podía descontar actualizaciones del sistema, SSH y otros tráficos. La observación demostrable es más limitada: durante varias horas de instalación en un VPS limpio, la red, las imágenes Docker y el cortafuegos del host cambiaron mucho antes de empezar a desplegar aplicaciones.

La diferencia con mi uso habitual de GitHub Runner y Docker Compose era notable. El Runner es una vía de ejecución dirigida por un workflow de GitHub; PanelAlpha está construyendo un plano de control completo para alojar aplicaciones. Es razonable que necesite más infraestructura si también tiene que gestionar aislamiento, dominios, bases de datos, archivos, copias y monitorización.

Detuve la prueba porque dedicar más tiempo a forzar su finalización ya no respondía a mi pregunta de selección, no para concluir que PanelAlpha era un mal producto. En esta máquina 1C2G, el arranque en frío y los cambios del host ya eran costes relevantes. No llegué a probar un despliegue de proyecto exitoso, la conservación de la versión anterior ante una publicación fallida ni la restauración de copias. La descripción oficial no sustituye esos resultados de ejecución pendientes.

Por qué conviene limitar también el permiso modify

No llegué a tener un servidor MCP operativo, pero conservé la auditoría previa del código fijado. ToolPolicy de v2.1.1 impone un límite por método HTTP a tres modos:

Modo	Métodos permitidos
readonly	GET
modify	GET, POST, PUT, PATCH
full	GET, POST, PUT, PATCH, DELETE

A primera vista, modify parece permitir cambios pero excluir eliminaciones peligrosas. Al revisar las herramientas MCP generadas, esa interpretación resulta demasiado simple.

project_delete usa DELETE y queda fuera del límite de modify. En cambio, backup_restore y project_push son POST y ambas llevan la marca IsDestructive. En esa capa del verb ceiling pueden estar dentro de modify.

Esto no es un hallazgo de acceso no autorizado. Antes de registrar herramientas, el Engine también aplica toolset, denylist y los ámbitos de TokenAbilities. Restaurar una copia exige además confirm=true. No completé las pruebas dinámicas de rechazo con tokens reales, por lo que no tengo evidencia de ejecución sobre la posibilidad de eludir esas protecciones.

La advertencia de ingeniería es más sencilla: prohibir DELETE no impide sobrescribir estados importantes. Restaurar una copia, trasladar staging a live o reconstruir un proyecto pueden ser operaciones POST. Empezaría un Coding Agent de infraestructura en readonly y limitaría de forma explícita toolset y denylist, en vez de confiar solo en los nombres de los modos.

Las observaciones de copias y telemetría también quedaron en el terreno del código y la documentación. Backups indica que no hay planificación integrada y que hace falta un programador externo, como cron; la restauración sobrescribe el estado actual del proyecto. La documentación de Telemetry distingue pae telemetry:disable de dejar PANELALPHA_MONITORING= vacío. El primero detiene las comprobaciones de salud programadas cada seis horas; el segundo se describe como mantener las comprobaciones locales sin enviar informes al endpoint de monitorización. No ejecuté ninguno de esos comportamientos: son hechos documentados de v2.1.1, no resultados de esta prueba del VPS.

Voy a conservar el Self-hosted Runner

Al comparar el experimento con mi flujo de ChatGPT Web, GitHub y Self-hosted Runner, la pregunta sobre cuál sustituye a cuál me parece demasiado estrecha.

	GitHub Self-hosted Runner	PanelAlpha Engine
Función principal	Ejecutar jobs controlados por workflows de GitHub	Gestionar el ciclo de vida de aplicaciones y hosting del servidor
Estado central	Commits, workflows y releases de Git	Estado de proyectos y hosting dentro del Engine
Integración con IA	El Agent modifica código/workflows y GitHub los ejecuta	El Agent opera el plano de control por MCP/API
Intervención en el host	Depende de lo que haga el workflow	Prepara Docker, red y cortafuegos desde la instalación
Alcance de mi evidencia	Cadena de producción existente en uso habitual	Instalación al 70 % y algunos cambios del host

Para mi blog, servicios pequeños y unos pocos proyectos autoalojados, mantengo GitHub, Self-hosted Runner y Docker Compose. No he demostrado que el Runner sea más seguro o más rápido. Ya está alineado con mi fuente de verdad, revisión por PR y ruta de publicación; un nuevo Hosting Control Plane con muchos privilegios todavía no compensa el estado y la infraestructura adicionales.

La elección tiene más sentido al gestionar decenas de aplicaciones con dominios, bases de datos, archivos, copias y aislamiento centralizados, y una necesidad real de que un Coding Agent los controle mediante una interfaz acotada. PanelAlpha no es un docker compose up más vistoso: intenta convertir el panel de hosting tradicional en una API de infraestructura accesible para agentes.

Terminar durante la instalación fue suficiente para esta decisión. No respondió cómo se usa PanelAlpha plenamente operativo, pero sí a mi necesidad concreta: publicar código revisado de forma fiable en unos pocos servidores no justifica, por ahora, añadir un plano de control VPS entero solo por la interacción con IA.

En otra prueba elegiría un VPS nuevo con más recursos. Empezaría por completar la matriz de rechazo MCP de readonly / modify / full, y después probaría publicaciones fallidas, restauración remota de copias y el comportamiento real de telemetry. Solo con esos resultados se puede valorar una entrada duradera para operaciones con IA, en vez de hablar únicamente de la instalación.