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 卷里。按计划导出 dump，并把副本放到服务器之外——连接里保存着你在其他服务的 API 令牌。
代码步骤没有沙箱隔离（此配置为 AP_EXECUTION_MODE=UNSANDBOXED）。服务器是你的，流程也是你的，所以可以接受。一旦让你不信任的人来搭建流程，就不再可以接受了。

如果你已经熟悉 n8n，思路是一样的——见 n8n VPS。选你用起来思路更顺的那个编辑器即可；两者在同样的套餐上都跑得很好。

Activepieces VPS：自托管的自动化平台

选哪个套餐

安装

检查 Webhook 是否正常

日常运维

相关内容

常见问题

评论

发表评论