# PanelAlpha Engine im Test: Kann AI VPS verwalten und GitHub Self-hosted Runner ersetzen?

> Canonical: https://vxi.me/de/posts/panelalpha-engine-vps-hosting-control-plane/
> Locale: de-de
> Published: 2026-10-08
> Updated: 2026-10-08
> Markdown: https://vxi.me/de/posts/panelalpha-engine-vps-hosting-control-plane.md

Mein Produktionsweg ist inzwischen recht klar: Der Code liegt in GitHub, ein geschützter Workflow entscheidet über Releases, und der Self-hosted Runner führt auf dem Server nur geprüfte Schritte aus. Als ich [PanelAlpha Engine auf Show HN](https://news.ycombinator.com/item?id=49991829) sah, interessierte mich weniger, ob KI beim Deployment helfen kann. Ich wollte wissen, wie eine MCP-Steuerung für den gesamten Anwendungslebenszyklus zu meinem vorhandenen Runner passt.

Ich habe PanelAlpha Engine v2.1.1 auf einem separaten VPS mit Ubuntu 24.04.2 getestet. Zum Zeitpunkt der Artikel-QA war diese Version noch das [aktuelle GitHub-Release](https://github.com/panelalpha/panelalpha-engine/releases/tag/v2.1.1). Auf 1 vCPU, 1,9 GiB RAM und 50 GB Speicher lief die Installation nach mehr als zwei Stunden noch in der Engine-Phase. Der zuletzt protokollierte Fortschritt war 70 %. An diesem Punkt beendete ich den Versuch.

Das beweist nicht, dass sich PanelAlpha nicht installieren lässt. Es zeigt vielmehr, dass es kein schlanker KI-Befehlsausführer ist, sondern eine Hosting Control Plane, die Docker, Netzwerke, Firewalls, Projektisolation, Backups und Monitoring berührt. Schon die unvollständige Installation gab mir genügend Anhaltspunkte, um die Idee eines Runner-Ersatzes neu zu bewerten.

## Ein frischer VPS statt des Produktions-Runners

Vor dem Versuch war Docker nicht installiert; `docker version` endete mit Code 127. Auch `iptables` und `nft` waren nicht verfügbar. Die lauschenden Ports gehörten im Wesentlichen zu SSH und chrony. Dieser Ausgangszustand ist wichtig: Die späteren Änderungen an Docker und Firewall ließen sich dadurch der Installation zuordnen und nicht einer alten Konfiguration.

Auch die [Installationsdokumentation](https://github.com/panelalpha/panelalpha-engine/blob/1e19bbf22a49c638f9e886fde653e02bbdc4bea5/docs/02-getting-started/install.md) empfiehlt einen neuen, dedizierten Debian- oder Ubuntu-VPS. Im Installer stehen außerdem Eingriffe in `systemd-resolved`, `/etc/resolv.conf`, Docker-Netzwerke und die Host-Firewall. Deshalb nutzte ich weder den bestehenden Blog-Runner noch einen anderen Produktionsserver.

Vor dem Start lud ich das Bootstrap-Skript als Datei herunter und berechnete SHA-256, statt es direkt mit `curl | sh` auszuführen:

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

Die getestete Engine-Version wurde ausdrücklich festgelegt:

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

Der erste Versuch kam nicht weit. Git fehlte; beim Nachinstallieren traf der Installer auf eine nicht verfügbare Abhängigkeit. Im tatsächlichen Log stand:

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

Dieser Lauf endete mit Code 1. Ich beschrieb ihn nicht als Fehler der PanelAlpha-Kerninstallation, denn er befand sich noch bei den Host-Abhängigkeiten. Spätere Versuche führten zunächst zu umfangreichen Systempaket-Upgrades; einer endete mit Code 141. Erst danach kam die Engine-Installation zu den Images, Netzwerken und Firewall-Regeln.

Ein Detail korrigierte meine erste Erwartung: Im Quellcode gibt es Pfade, die `systemd-resolved` und `resolv.conf` ändern. Auf diesem VPS existierte jedoch von Anfang an kein `systemd-resolved.service`, und die Resolver-Datei verwendete bereits externe DNS-Server. Eine Änderung der DNS-Datei vor und nach dem Lauf habe ich daher nicht beobachtet. Eine Fähigkeit im Quellcode und ein tatsächlich beobachteter Eingriff sind unterschiedliche Belege.

## Bei 70 % gestoppt, aber der Host war bereits verändert

Vor dem Ende erfasste ich den Host-Zustand erneut. Docker Engine 29.8.2 war installiert, während die PanelAlpha-Fortschrittsdatei weiterhin Folgendes meldete:

```text
step: Installing PanelAlpha engine
progress: 70
```

`docker ps -a` war leer. Daraus zehn laufende Hintergrundcontainer abzuleiten wäre falsch gewesen. Nachweisbar waren sechs PanelAlpha-Images, darunter composer, DNS proxy, Exim, metrics, Pure-FTPd und SFTP. Für das größte, composer, meldete Docker 795 MB disk usage.

Deutlicher waren die Netzwerkänderungen. Anfangs fehlten `iptables` und `nft`; später gab es UFW-/Docker-Regeln sowie PanelAlpha-Ketten wie `PA-BUILD-EGRESS`, `PA-PUBLISHED`, `PA-TENANT-INPUT` und `PA-TENANT-NET`. Die lauschenden Ports waren allerdings weiterhin nur SSH und chrony. Die Engine war noch nicht bereit, externe Anfragen zu bedienen.

Am Ende zeigte `eth1` einen kumulierten RX-Zähler von 1,508,426,817 bytes. Ich würde daraus nicht „PanelAlpha hat 1,5 GB heruntergeladen“ machen: Der Ausgangssnapshot enthielt keinen RX-Zähler, sodass sich Systemupdates, SSH und anderer Verkehr nicht herausrechnen ließen. Gesichert ist die engere Beobachtung: Während einer mehrstündigen Installation auf einem frischen VPS änderten sich Netzwerk, Docker-Images und Host-Firewall erheblich, bevor überhaupt ein Anwendungsdeployment begann.

Das unterschied sich deutlich von meinem Alltag mit GitHub Runner und Docker Compose. Der Runner ist ein Ausführungskanal für GitHub-Workflows. PanelAlpha errichtet eine vollständige Hosting-Steuerung für Anwendungen. Dass dafür mehr Grundlagen nötig sind, ist nachvollziehbar: Sie soll auch Isolation, Domains, Datenbanken, Dateien, Backups und Monitoring verwalten.

Ich brach nicht ab, um PanelAlpha als ungeeignet zu erklären. Noch mehr Zeit in eine erzwungene Fertigstellung zu investieren hätte meine ursprüngliche Auswahlfrage nicht mehr beantwortet. Auf dieser 1C2G-Maschine waren Kaltstart und Eingriffe in den Host bereits relevante Kosten. Erfolgreiche Projektdeployments, das Beibehalten der alten Version bei fehlgeschlagenen Releases und Backup-Wiederherstellung habe ich nicht getestet. Offizielle Beschreibungen ersetzen diese fehlenden Laufzeitnachweise nicht.

## Weshalb auch `modify` sorgfältig begrenzt werden muss

Der MCP-Server wurde nicht betriebsbereit, aber das frühere Audit des festgelegten Quellstands blieb erhalten. [ToolPolicy in v2.1.1](https://github.com/panelalpha/panelalpha-engine/blob/1e19bbf22a49c638f9e886fde653e02bbdc4bea5/core/app/Mcp/ToolPolicy.php) legt für drei Modi eine Obergrenze anhand der HTTP-Methoden fest:

| Modus | Erlaubte Methoden |
| --- | --- |
| `readonly` | GET |
| `modify` | GET, POST, PUT, PATCH |
| `full` | GET, POST, PUT, PATCH, DELETE |

Auf den ersten Blick klingt `modify` nach Änderungen ohne gefährliches Löschen. Die erzeugten MCP-Werkzeuge zeigen, warum das zu kurz greift.

`project_delete` verwendet DELETE und liegt damit außerhalb der Methodengrenze von `modify`. Dagegen sind [`backup_restore`](https://github.com/panelalpha/panelalpha-engine/blob/1e19bbf22a49c638f9e886fde653e02bbdc4bea5/core/app/Mcp/Tools/Api/Backups/BackupRestoreTool.php) und [`project_push`](https://github.com/panelalpha/panelalpha-engine/blob/1e19bbf22a49c638f9e886fde653e02bbdc4bea5/core/app/Mcp/Tools/Api/Projects/ProjectPushTool.php) POST-Operationen und tragen beide die Markierung `IsDestructive`. Auf Ebene dieses verb ceiling können sie somit in `modify` enthalten sein.

Das ist keine Feststellung einer Schwachstelle für unbefugten Zugriff. Vor der Werkzeugregistrierung berücksichtigt die Engine zusätzlich toolset, denylist und die TokenAbilities-Scopes. Die Backup-Wiederherstellung verlangt außerdem `confirm=true`. Dynamische Ablehnungstests mit echten Tokens habe ich nicht abgeschlossen; für eine Umgehbarkeit dieser Schutzmechanismen gibt es aus meinem Versuch keine Belege.

Die praktische Lehre ist einfacher: DELETE zu verbieten verhindert nicht automatisch das Überschreiben wichtiger Zustände. Eine Backup-Wiederherstellung, das Übertragen von staging nach live oder ein Projekt-Neuaufbau kann per POST erfolgen. Bei einem Coding Agent würde ich mit `readonly` beginnen und toolset sowie denylist ausdrücklich eingrenzen, statt auf die drei Modusnamen zu vertrauen.

Auch Backup und Telemetrie blieben bei Quellen- und Dokumentationsbefunden. Laut [Backups-Dokumentation](https://github.com/panelalpha/panelalpha-engine/blob/1e19bbf22a49c638f9e886fde653e02bbdc4bea5/docs/05-capabilities/backups.md) gibt es keine integrierte Zeitplanung; dafür braucht es beispielsweise externes cron. Eine Wiederherstellung überschreibt den aktuellen Projektzustand. Die Telemetrie-Dokumentation unterscheidet `pae telemetry:disable` von einem leeren `PANELALPHA_MONITORING=`. Ersteres beendet die geplanten Gesundheitsprüfungen im Sechs-Stunden-Takt; Letzteres soll lokale Prüfungen beibehalten, ohne Berichte an den Monitoring-Endpunkt zu senden. Ich habe diese Abläufe nicht dynamisch ausgeführt. Es sind Dokumentationsangaben zu v2.1.1, keine gemessenen Ergebnisse dieses VPS-Tests.

## Ich behalte meinen Self-hosted Runner

Im Vergleich mit meinem bestehenden [ChatGPT-Web-, GitHub- und Self-hosted-Runner-Workflow](/de/posts/chatgpt-web-github-self-hosted-runner/) war die Frage nach einem Ersatz offenbar zu eng gestellt.

| | GitHub Self-hosted Runner | PanelAlpha Engine |
| --- | --- | --- |
| Hauptaufgabe | Jobs unter Kontrolle von GitHub-Workflows ausführen | Lebenszyklus von Anwendungen und Server-Hosting verwalten |
| Zentraler Zustand | Git-Commits, Workflows und Releases | Projekt- und Hosting-Zustand innerhalb der Engine |
| KI-Anbindung | Agent ändert Code/Workflows, GitHub führt sie aus | Agent bedient die Steuerung direkt über MCP/API |
| Eingriffe in den Host | Abhängig vom Workflow | Docker-, Netzwerk- und Firewall-Grundlagen schon bei der Installation |
| Mein Nachweis | Bestehende Produktionskette regelmäßig im Einsatz | Installation bis 70 % und ein Teil der Host-Änderungen |

Für meinen Blog, kleine Dienste und wenige selbst gehostete Projekte bleibe ich bei GitHub, Self-hosted Runner und Docker Compose. Das beweist weder höhere Sicherheit noch bessere Leistung des Runners. Er passt bereits zu meiner maßgeblichen Zustandsquelle, PR-Prüfung und Release-Kette. Eine weitere hochprivilegierte Hosting Control Plane gleicht die zusätzlichen Zustände und Infrastrukturkosten derzeit nicht aus.

Bei Dutzenden Anwendungen mit zentral verwalteten Domains, Datenbanken, Dateien, Backups und Isolation sieht die Entscheidung anders aus. Wenn ein Coding Agent diese Ressourcen tatsächlich über eine begrenzte Schnittstelle bedienen soll, ist PanelAlphas Positionierung plausibel. Es ist kein schickeres `docker compose up`, sondern der Versuch, ein herkömmliches Hosting-Panel als aufrufbare Infrastruktur-API bereitzustellen.

Für meine Entscheidung reichte auch der Abbruch während der Installation. Über den Komfort eines vollständig laufenden PanelAlpha sagt er nichts aus. Für das zuverlässige Ausrollen geprüften Codes auf wenige Server sehe ich aber derzeit keinen Grund, allein für KI-Bedienung eine komplette VPS-Steuerung einzuführen.

Beim nächsten Test würde ich einen frischen, leistungsfähigeren VPS nehmen und zuerst die MCP-Ablehnungsmatrix für `readonly / modify / full` prüfen. Danach kämen fehlgeschlagene Releases, Wiederherstellung entfernter Backups und das tatsächliche Telemetrieverhalten. Erst damit lässt sich über einen langfristigen KI-Betriebseinstieg diskutieren, statt nur über das Installationserlebnis.