Activepieces 需要多少記憶體？

預設的 docker-compose.yml 會啟動應用程式和五個 worker；在我們的測試伺服器上，加上 Postgres 和 Redis 約佔 2.6–3 GB。只用一個 worker 時約 1.6 GB。Small-IP（4 GB）跑預設配置綽綽有餘；Micro-IP（2 GB）只有在一個 worker 加 swap 檔案時才能用。

流程發布不了，Webhook 回傳 404。哪裡出了問題？

檢查 AP_FRONTEND_URL。worker 透過這個位址連到應用程式，如果它還是 http://localhost:8080，那麼 worker 容器裡的 «localhost» 就是 worker 自己。它們連不上，發布卡住，Webhook 回傳 404。首次啟動前請填入你真正的 https:// 網域。

需要獨立 IP 嗎？

如果你用 Webhook，就需要——而大多數人都會用。呼叫你流程的服務必須能連到你網域的 80 和 443 連接埠，而 NAT 方案從外部只接受你的 SSH 連接埠。

任何人都能在我的實例上註冊嗎？

只有第一個人可以。在我們的測試中，第一次註冊成功，第二次收到 «User is not invited to the platform»：第一個帳號之後，只能透過邀請註冊。所以網站一上線就立刻建立你的帳號，別讓別人先找到這個頁面。

程式碼步驟是隔離執行的嗎？

預設不是：compose 配置用 AP_EXECUTION_MODE=UNSANDBOXED 直接在 worker 裡執行程式碼步驟。只要建立流程的只有你和你信任的人，這沒問題。在這種安裝上不要把編輯器權限交給陌生人。

Activepieces VPS：自架的自動化平台

在自己的伺服器上運行開源自動化建構工具 Activepieces：不按任務計費，Webhook 用你自己的網域。經過實測的安裝步驟，以及 URL 的陷阱。

託管的自動化服務按任務收費，計費器連那些根本算不上工作的事也照算不誤。一個每五分鐘檢查一次訂閱來源的流程，在做出任何有用的事之前，每月就已經是 8640 次執行。把同一個流程放到你自己的伺服器上，帳單就只是伺服器本身。

Activepieces 是一個開源的自動化建構工具：觸發器、步驟、分支、幾百個現成的整合，現成的不夠用時還有程式碼步驟。社群版採用 MIT 授權，用 Docker Compose 在一台小伺服器上就能穩穩運行。

選哪個方案

我們把它裝在測試伺服器上量了一下。預設的 compose 檔案會啟動應用程式和五個 worker：加上 Postgres 和 Redis，約佔 2.6–3 GB 記憶體。減到一個 worker 後降到約 1.6 GB。

你要運行的	方案
幾個個人流程，一個 worker	Micro-IP：2 vCPU、2 GB、25 GB（每月 $10），需加 swap
預設配置：五個 worker、團隊流程、Webhook	Small-IP：4 vCPU、4 GB、35 GB（每月 $16）
大量同時執行，繁重的程式碼步驟	Medium-IP：6 vCPU、6 GB、45 GB（每月 $20）

請選擇有獨立 IPv4 的方案。自架它的主要理由就是 Webhook，而呼叫 Webhook 的服務必須能連到 80 和 443 連接埠；在 NAT 方案上，從外部只能連到 SSH 連接埠。伺服器位於歐盟，共有兩個地點，下單時可看到是否有空位。可以用加密貨幣付款，無需 KYC。

安裝

先把一個網域（例如 flows.example.com）指向伺服器。然後在 Ubuntu 24.04 或 Debian 12 上以 root 身分執行：

curl -fsSL https://get.docker.com | sh
git clone --depth 1 https://github.com/activepieces/activepieces.git
cd activepieces
sh tools/deploy.sh

deploy.sh 會把 .env.example 複製成 .env，並填入隨機密鑰。首次啟動前，修改 .env 裡的兩行和 compose 檔案裡的一行：

sed -i 's|^AP_FRONTEND_URL=.*|AP_FRONTEND_URL=https://flows.example.com|; s|^AP_TELEMETRY_ENABLED=.*|AP_TELEMETRY_ENABLED=false|' .env
sed -i "s|- '8080:80'|- '127.0.0.1:8080:80'|" docker-compose.yml

關鍵是第一行。AP_FRONTEND_URL 不只用於介面裡的連結：worker 也是透過它連到應用程式。如果保留 http://localhost:8080，每個 worker 容器都會在自己內部找應用程式，找不到，你的流程就永遠發布不了。我們正好踩到這個坑：worker 記錄裡出現 «Socket.IO connection error»，發布請求卡住，Webhook 回傳 404。換成真正的網域後，同一個流程順利發布，Webhook 也跑通了。

對 docker-compose.yml 執行的 sed 讓 8080 連接埠只監聽 localhost。Docker 發布的連接埠會繞過 ufw，不加這一行，應用程式就會在你的 HTTPS 旁邊暴露在一個裸連接埠上。

在 Micro-IP 上，還要減到一個 worker：

sed -i 's/replicas: 5/replicas: 1/' docker-compose.yml

接下來是 HTTPS 和啟動：

apt install -y caddy
cat > /etc/caddy/Caddyfile <<'EOF'
flows.example.com {
    reverse_proxy 127.0.0.1:8080
}
EOF
systemctl reload caddy
ufw allow 22/tcp && ufw allow 80/tcp && ufw allow 443/tcp && ufw enable
docker compose -p activepieces up -d

等半分鐘，打開 https://flows.example.com，馬上建立你的帳號。第一個註冊的人擁有整個平台；之後只能透過邀請註冊。

檢查 Webhook 是否正常

建立一個使用 Webhook 觸發器（Catch Webhook）的流程，隨便加一個步驟，然後發布。觸發器面板裡會顯示 URL。向它送出一個測試事件：

curl -X POST https://flows.example.com/api/v1/webhooks/YOUR_FLOW_ID \
  -H 'content-type: application/json' \
  -d '{"event":"payment.paid","amount":16}'

你應該收到 200，執行紀錄會以成功狀態出現在 Runs 裡。如果收到的是 404，回頭檢查 AP_FRONTEND_URL。

日常維運

更新。 compose 檔案固定了一個確切版本（撰寫時為 0.92.2）。修改 docker-compose.yml 裡的標籤，然後執行 docker compose -p activepieces pull && docker compose -p activepieces up -d。先瀏覽一下版本說明；自動化工具很喜歡替東西改名。
備份。 流程、連線和執行歷史都存放在 Postgres 的 volume 裡。依排程匯出 dump，並把副本放到伺服器之外——連線裡保存著你在其他服務的 API 權杖。
程式碼步驟沒有沙箱隔離（此配置為 AP_EXECUTION_MODE=UNSANDBOXED）。伺服器是你的，流程也是你的，所以可以接受。一旦讓你不信任的人來建立流程，就不再可以接受了。

如果你已經熟悉 n8n，思路是一樣的——見 n8n VPS。選你用起來思路更順的那個編輯器即可；兩者在同樣的方案上都跑得很好。

Activepieces VPS：自架的自動化平台

選哪個方案

安裝

檢查 Webhook 是否正常

日常維運

相關內容

常見問題

評論

發表評論