Il mio percorso di pubblicazione in produzione è ormai abbastanza stabile: il codice entra in GitHub, un workflow protetto decide quando pubblicarlo e il Self-hosted Runner esegue sul server soltanto i passaggi già revisionati. Dopo aver visto PanelAlpha Engine su Show HN, la domanda non era tanto se l’IA potesse aiutarmi con un deployment. Volevo capire come un piano di controllo MCP per l’intero ciclo di vita delle applicazioni si rapportasse al Runner esistente.

Ho provato PanelAlpha Engine v2.1.1 su un VPS separato con Ubuntu 24.04.2. Al momento della QA dell’articolo era ancora la versione più recente su GitHub. Su una macchina con 1 vCPU, 1,9 GiB di RAM e 50 GB di disco, dopo oltre due ore l’installazione era ancora nella fase Engine. L’ultimo avanzamento registrato era il 70 % e ho interrotto l’esperimento.

Questo non dimostra che PanelAlpha non sia installabile. Mostra invece che non si tratta di un semplice esecutore di comandi IA, ma di una Hosting Control Plane che interviene su Docker, rete, firewall, isolamento dei progetti, backup e monitoraggio. Anche senza completare l’installazione avevo elementi sufficienti per ripensare all’idea di sostituire il Self-hosted Runner.

Un VPS pulito, non il Runner di produzione

Prima della prova non c’era Docker e docker version restituiva il codice 127. Mancavano anche iptables e nft; le porte in ascolto erano sostanzialmente quelle di SSH e chrony. Questa baseline permette di attribuire le successive modifiche a Docker e al firewall all’installazione, anziché a vecchie configurazioni della macchina.

La documentazione di installazione indica infatti un VPS Debian o Ubuntu nuovo e dedicato. Il sorgente dell’installer gestisce anche systemd-resolved, /etc/resolv.conf, le reti Docker e il firewall dell’host. Per questo ho lasciato fuori dalla prova il Runner del blog e gli altri server di produzione.

Prima di eseguire il bootstrap, l’ho scaricato come file e ne ho calcolato lo SHA-256, invece di passarlo direttamente a curl | sh:

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

Ho quindi fissato esplicitamente la versione:

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

Il primo tentativo si è fermato presto. Git non era presente e l’installer ha provato ad aggiungerlo, ma una dipendenza risultava non installabile. Questo è il log effettivo:

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).

Il tentativo è terminato con codice 1. Non l’ho definito un fallimento dell’installazione del nucleo di PanelAlpha: si era ancora nella preparazione delle dipendenze dell’host. Le verifiche successive hanno avviato un aggiornamento consistente dei pacchetti di sistema; una delle esecuzioni è uscita con codice 141. Proseguendo, l’installazione Engine è arrivata alle immagini, alla rete e al firewall.

Un dettaglio ha anche corretto la mia aspettativa iniziale. Il sorgente prevede modifiche a systemd-resolved e resolv.conf, ma il VPS non aveva systemd-resolved.service già all’inizio e il resolver usava DNS esterni. In questa prova non ho osservato modifiche al file DNS fra prima e dopo. Una capacità presente nel codice e un comportamento realmente osservato su un host sono prove diverse.

Ferma al 70 %, ma l’host era già cambiato

Prima di terminare ho raccolto un’altra istantanea dello stato della macchina. Docker Engine 29.8.2 era installato, mentre il file di avanzamento di PanelAlpha riportava ancora:

step: Installing PanelAlpha engine
progress: 70

docker ps -a era vuoto. Parlare di dieci container in background già attivi sarebbe stato scorretto. Ho verificato sei immagini PanelAlpha: composer, DNS proxy, Exim, metrics, Pure-FTPd e SFTP. Per composer, la più grande, Docker riportava 795 MB di disk usage.

I cambiamenti di rete erano più evidenti. Nella baseline non c’erano iptables e nft; in seguito erano presenti regole UFW / Docker e catene come PA-BUILD-EGRESS, PA-PUBLISHED, PA-TENANT-INPUT e PA-TENANT-NET. Le porte in ascolto restavano però soltanto SSH e chrony. L’Engine non era ancora pronto a servire richieste esterne.

Alla fine, il contatore RX cumulativo di eth1 era 1,508,426,817 bytes. Non lo trasformerei nell’affermazione «PanelAlpha ha scaricato 1,5 GB»: nella baseline non avevo annotato RX e non potevo sottrarre aggiornamenti di sistema, SSH o altro traffico. L’osservazione verificata è più circoscritta: durante diverse ore di installazione su un VPS pulito, rete, immagini Docker e firewall erano cambiati sensibilmente prima che iniziasse il deployment di un’applicazione.

Era diverso dal mio uso abituale di GitHub Runner e Docker Compose. Il Runner è un canale di esecuzione guidato da un workflow GitHub; PanelAlpha sta costruendo un intero piano di controllo per ospitare applicazioni. Richiedere una base più ampia è comprensibile se bisogna gestire anche isolamento, domini, database, file, backup e monitoraggio.

Ho interrotto perché insistere fino a completare l’installazione non avrebbe più risposto alla mia domanda iniziale, non per dichiarare PanelAlpha un cattivo prodotto. Su questa macchina 1C2G, l’avvio a freddo e le modifiche all’host erano già costi da considerare. Non ho verificato deployment riusciti, conservazione della vecchia versione dopo un rilascio fallito o ripristino dei backup. Le descrizioni ufficiali non sostituiscono questi test di runtime non eseguiti.

Perché anche il permesso modify richiede cautela

Non sono arrivato a un server MCP operativo, ma ho conservato l’audit del sorgente fissato. ToolPolicy in v2.1.1 impone un limite di metodi HTTP per tre modalità:

Modalità	Metodi consentiti
readonly	GET
modify	GET, POST, PUT, PATCH
full	GET, POST, PUT, PATCH, DELETE

A prima vista, modify sembra significare «può modificare, ma non cancellare in modo pericoloso». Le procedure MCP generate mostrano perché questa lettura è incompleta.

project_delete usa DELETE e rimane fuori dal limite di modify. Invece backup_restore e project_push sono POST ed entrambe portano il marcatore IsDestructive. Al livello di questo verb ceiling possono quindi rientrare in modify.

Non è una conclusione di accesso non autorizzato. Prima di registrare i tool, l’Engine applica anche toolset, denylist e scope di TokenAbilities. Il ripristino richiede inoltre confirm=true. Non ho completato i test dinamici di rifiuto con token reali, quindi non ho prove di runtime sulla possibilità di aggirare queste protezioni.

Il richiamo ingegneristico è più semplice: vietare DELETE non impedisce automaticamente di sovrascrivere uno stato importante. Un ripristino, il passaggio da staging a live o la ricostruzione di un progetto possono usare POST. Per collegare un Coding Agent partirei da readonly, restringendo esplicitamente toolset e denylist, senza affidarmi soltanto ai nomi delle modalità.

Anche backup e telemetria sono rimasti nel campo del sorgente e della documentazione. Backups dichiara che non esiste una pianificazione integrata e serve uno scheduler esterno, come cron; il ripristino sovrascrive lo stato corrente del progetto. La documentazione Telemetry distingue pae telemetry:disable dal lasciare PANELALPHA_MONITORING= vuoto. Il primo ferma i controlli di salute pianificati ogni sei ore; il secondo viene descritto come mantenere i controlli locali senza inviare rapporti all’endpoint di monitoraggio. Non ho eseguito dinamicamente questi comportamenti. Sono informazioni documentate di v2.1.1, non risultati della prova del VPS.

Per ora tengo il Self-hosted Runner

Confrontando questa prova con il mio workflow ChatGPT Web, GitHub e Self-hosted Runner, mi sembra che la domanda sulla sostituzione fosse troppo stretta.

	GitHub Self-hosted Runner	PanelAlpha Engine
Compito principale	Eseguire job controllati dai workflow GitHub	Gestire il ciclo di vita di applicazioni e hosting
Stato centrale	Commit Git, workflow e release	Stato di progetti e hosting nell’Engine
Integrazione IA	L’Agent modifica codice/workflow, GitHub li esegue	L’Agent opera il piano di controllo tramite MCP/API
Intervento sull’host	Dipende dal contenuto del workflow	Prepara Docker, rete e firewall durante l’installazione
Evidenza della prova	Catena di produzione esistente usata regolarmente	Installazione al 70 % e alcune modifiche all’host

Per il blog, piccoli servizi e pochi progetti auto-ospitati mantengo GitHub, Self-hosted Runner e Docker Compose. Non ho dimostrato che il Runner sia più sicuro o più veloce. È già allineato con la mia fonte di verità, la revisione tramite PR e il percorso di rilascio. Un nuovo Hosting Control Plane altamente privilegiato non compensa ancora lo stato e l’infrastruttura aggiuntivi.

Gestire decine di applicazioni, centralizzando domini, database, file, backup e isolamento, è invece uno scenario più coerente con PanelAlpha. Se un Coding Agent deve davvero controllare queste risorse tramite un’interfaccia delimitata, la proposta è più sensata. Non è un docker compose up più appariscente: cerca di trasformare un tradizionale hosting panel in API infrastrutturali utilizzabili da un Agent.

Fermarmi all’installazione è stato sufficiente per questa scelta. Non so come si usi PanelAlpha completamente operativo, ma pubblicare in modo affidabile codice revisionato su pochi server non giustifica per me, oggi, un’intera control plane VPS solo per l’interazione con l’IA.

Se lo proverò di nuovo userò un VPS nuovo con più risorse, partendo dalla matrice di rifiuto MCP per readonly / modify / full. Poi verificherò rilasci falliti, ripristino di backup remoti e il comportamento reale di telemetry. Solo allora sarà possibile discutere di un ingresso stabile per operazioni IA, e non soltanto dell’esperienza d’installazione.