我現在的正式環境發佈流程已經比較固定：程式碼進 GitHub，受保護的 workflow 決定何時發佈，Self-hosted Runner 只負責在伺服器上執行已經審查過的步驟。前陣子看到 PanelAlpha Engine 的 Show HN，我最想確認的不是「AI 能不能幫我部署」，而是另一個更實際的問題：如果把應用程式生命週期交給 MCP 控制平面，它和現有 Runner 到底是什麼關係？

我用一台獨立的 Ubuntu 24.04.2 測試 VPS 跑了 PanelAlpha Engine v2.1.1。這個版本截至本次 QA 仍是專案的 GitHub latest release。結果沒有得到漂亮的「一鍵部署成功」：在 1 vCPU、1.9 GiB RAM、50 GB 磁碟的機器上，安裝超過兩小時仍停在 Engine 安裝階段，最後記錄的進度是 70%，我主動停止了後續實驗。

這不代表 PanelAlpha 裝不起來。它真正給我的資訊是：這不是輕量的 AI 指令執行器，而是一套會進入 Docker、網路、防火牆、專案隔離、備份和監控邊界的 Hosting Control Plane。安裝沒跑完，反而足夠讓我重新判斷它是否應該取代現有的 Self-hosted Runner。

我沒有裝到正式環境，先看乾淨 VPS 會發生什麼

這次從乾淨 VPS 開始。實驗前沒有 Docker，docker version 回傳 127；系統也沒有可用的 iptables 和 nft 指令，監聽連接埠基本上只有 SSH 與 chrony。這個基準狀態很重要，因為後面觀察到的 Docker 和防火牆變化，至少能明確歸因於安裝過程，而不是機器原本留下的設定。

PanelAlpha 自己的 安裝文件 也寫得很清楚：更適合新的、專用的 Debian / Ubuntu VPS。原始碼中的安裝程式還包含 systemd-resolved、/etc/resolv.conf、Docker 網路和主機防火牆處理邏輯。所以我沒有拿既有的部落格 Runner 或其他正式環境機器做實驗。

實際執行前，我先將 bootstrap 下載為檔案並計算 SHA-256，而不是直接 curl | sh：

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

測試版本隨後固定為 v2.1.1：

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

第一輪沒有走遠。安裝程式發現系統缺少 Git，嘗試安裝時遇到依賴套件不可用，實際記錄如下：

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

這一輪的結束碼是 1。我沒有把它寫成「PanelAlpha 核心安裝失敗」，因為失敗點仍在主機依賴準備階段。後續繼續驗證時，流程進入大規模系統套件升級，其中一次以 141 結束。再繼續之後，Engine 安裝才推進到後面的映像、網路和防火牆階段。

另有一個細節修正了我最初的預期。原始碼確實存在修改 systemd-resolved 和 resolv.conf 的路徑，但這台 VPS 一開始就沒有 systemd-resolved.service，而且 resolv.conf 原本使用外部 DNS，所以本次執行前後，DNS 檔案沒有可觀察的變化。原始碼能力和這一次機器上真正發生的事，應該分開說明。

安裝停在 70%，主機卻已經不是原本的狀態

實驗結束前，我再次擷取機器狀態。Docker Engine 已經安裝完成，版本是 29.8.2；PanelAlpha 進度檔案仍顯示：

step: Installing PanelAlpha engine
progress: 70

docker ps -a 仍為空。這次實驗不是「10 個背景容器已經執行」。能直接確認的是，機器上出現了 6 個 PanelAlpha 映像，包括 composer、DNS proxy、Exim、metrics、Pure-FTPd 和 SFTP。最大的 composer 映像由 Docker 回報為 795 MB disk usage。

更明顯的變化發生在網路層。基準狀態中 iptables / nft 工具不存在；安裝推進後，主機有了 UFW / Docker 規則，並出現 PA-BUILD-EGRESS、PA-PUBLISHED、PA-TENANT-INPUT、PA-TENANT-NET 等 PanelAlpha 鏈。同時，監聽連接埠快照仍只有 SSH 和 chrony，Engine 本身尚未準備好對外提供服務。

結束時，eth1 的累計 RX 計數是 1,508,426,817 bytes。這個數字我不會直接寫成「PanelAlpha 下載了 1.5 GB」，因為基準檔案沒有記錄介面 RX 計數，沒法扣除系統升級、SSH 和其他流量。能確認的是：在持續數小時的乾淨 VPS 安裝期間，網路、Docker 映像和主機防火牆都發生明顯變化，而應用程式部署尚未開始。

這和我平常使用 GitHub Runner + Docker Compose 的感受很不一樣。Runner 比較像受 GitHub workflow 驅動的執行通道；PanelAlpha 則在建立整套應用程式託管控制平面。後者需要更多基礎設施並不奇怪，因為它還要處理專案隔離、網域、資料庫、檔案、備份和監控等生命週期。

所以我最後停止測試，不是為了下「PanelAlpha 不行」的結論，而是繼續耗時間把它硬裝完，已經不足以回答最初的選型問題。對這台 1C2G 機器而言，控制平面的冷啟動與主機改動本身，已是必須納入的成本。專案是否能部署成功、失敗的發佈是否保留舊版本、備份是否能還原，我這次都沒有測到，官方說明也不等於自己的執行結果。

modify 權限為什麼仍需謹慎

雖然沒跑到 MCP 伺服器，我仍保留了先前固定版本的原始碼稽核。PanelAlpha v2.1.1 的 ToolPolicy 依 HTTP 方法，為三種權限模式設定上限：

權限模式	允許的方法
readonly	GET
modify	GET、POST、PUT、PATCH
full	GET、POST、PUT、PATCH、DELETE

乍看之下，modify 很像「能修改，但不准危險刪除」。繼續看產生的 MCP 工具，就會發現這個理解不夠完整。

project_delete 是 DELETE，所以不會通過 modify 的方法上限；但 backup_restore 和 project_push 都是 POST，也都帶有 IsDestructive 標記。只看這層 verb ceiling，它們可以落在 modify 範圍內。

這不是「未授權漏洞」的結論。Engine 在註冊工具前，還會套用 toolset、denylist 和 TokenAbilities 的 token 範圍；備份還原請求也要求 confirm=true。我沒有完成真實 token 的動態拒絕測試，所以並沒有執行證據可以判斷這些保護是否能被繞過。

它給我的工程提醒更簡單：替 Coding Agent 設計基礎設施權限時，不允許 DELETE，不等於不會覆寫重要狀態。還原備份、將 staging 推到 live、重建專案，都可能經由 POST 完成。若真要接入 Agent，我會從 readonly 開始，再明確縮小 toolset 和 denylist，而不只看三個模式名稱。

備份與 telemetry 這次也停留在原始碼與官方文件的範圍。Backups 文件 明確表示沒有內建排程，需要外部 cron 等工具；還原會覆寫目前的專案狀態。Telemetry 文件則區分 pae telemetry:disable 和將 PANELALPHA_MONITORING= 留空：前者停掉每六小時的健康檢查，後者的官方描述是保留本機檢查，但不向監控端點傳送報告。這些行為我未曾動態執行，只能當作 v2.1.1 的文件事實。

我現在仍保留 Self-hosted Runner

把這輪實驗與既有的 ChatGPT Web + GitHub + Self-hosted Runner 工作流程 放在一起看，我反而覺得「誰取代誰」這個問題太窄。

	GitHub Self-hosted Runner	PanelAlpha Engine
主要職責	執行受 GitHub workflow 控制的 job	管理應用程式與伺服器託管生命週期
核心狀態	Git commit、workflow、release	Engine 內的專案與託管狀態
AI 接入方式	Agent 改程式碼或 workflow，再由 GitHub 執行	Agent 經 MCP / API 直接操作控制平面
主機介入	取決於 workflow 本身做什麼	安裝時就建立 Docker、網路與防火牆基礎
本次驗證範圍	既有正式環境流程持續使用	僅安裝到 70% 與部分主機變化

對我的部落格、小型服務和少數自行託管專案而言，目前仍選擇 GitHub + Self-hosted Runner + Docker Compose。並不是因為我證明 Runner 更安全或效能更好，而是它已經符合現有的 source of truth、PR 審查和發佈路徑。新增一個高權限 Hosting Control Plane，目前還抵銷不了額外狀態與基礎設施的成本。

反過來，如果要管理數十個應用程式，統一處理網域、資料庫、檔案、備份、專案隔離，也確實希望 Coding Agent 經由受限制的介面管理資源，PanelAlpha 的定位就合理許多。它不只是更花俏的 docker compose up，而是在嘗試將傳統 hosting panel 轉成 Agent 可以呼叫的基礎設施 API。

這次實驗停在安裝階段，對目前的選擇卻已足夠。它沒有回答「PanelAlpha 完整運作後好不好用」，但已回答我真正需要決定的事：如果目標只是將審查過的程式碼可靠地發佈到幾台伺服器，目前沒有理由只為了 AI 操作體驗，另外引入整套 VPS 控制平面。

以後再測，我會換資源更充裕的全新 VPS，先完成 readonly / modify / full 的 MCP 拒絕矩陣，再驗證失敗發佈、遠端備份還原與 telemetry 的實際行為。到那時，才適合討論長期 AI 維運入口，而不只是安裝體驗。