Activepieces：开源自动化工作流平台

为什么需要 Activepieces：自托管自动化的痛点解药

团队做集成自动化，通常绕不开两个选择。一是采购 Zapier 这类商业 SaaS：上手快，但按任务量计费，数据要经过第三方服务器，核心逻辑无法查看与改造；二是让工程师写胶水脚本——cron 定时拉起、requests 调接口、手动记录日志。脚本方案初期灵活，但每接入一个系统就要维护一套鉴权、重试与错误处理，两三个服务之后代码量就开始失控，业务人员也无法参与修改。对做 AI 应用的团队还有第三层痛点：把 LLM 调用、向量库写入和外部系统操作编排在一起，纯代码实现既不直观，也难以在关键节点插入人工审核。

Activepieces 给出的解决方案是把自动化本身做成可视化产品：流程以触发器为起点（Webhook、定时 Cron、SaaS 应用事件），经过分支、循环、代码步骤或 200+ 现成连接器，最终落到某个动作。整套引擎以 MIT 协议开源，可直接拉取官方镜像，跑在你自己控制的服务器上；同一套 Flow 也可以用官方云版本免运维运行。这种「开源自托管 + 托管云服务」的两条路径，让团队按数据合规要求和运维成本自由选择。

与同类工具相比，Activepieces 刻意站在两个交叉点：比 n8n 更产品化，普通业务人员能看懂流程；比 Zapier 更开放，MIT 协议、可自托管、可嵌入到自家 SaaS 产品中。它不追求连接器数量的压倒性优势，而是用「连接器 + 通用 HTTP/代码步骤」保证覆盖面，把差异化放在部署自由与协作体验上。

安装与环境配置：3 步就绪

自托管需要 Docker 20.10+ 与 Docker Compose v2，用 docker compose version 确认版本。官方发行镜像是 ghcr.io/activepieces/activepieces，运行依赖 PostgreSQL 14+，推荐将两者放在同一个 Compose 文件中统一管理。下面给出可直接使用的 docker-compose.yml，把密码与密钥替换成自己的值即可：

启动与验证：

三个环境变量必须正确：AP_JWT_SECRET 用于登录令牌签名；AP_ENCRYPTION_KEY 用于加密连接器授权凭证，建议使用 32 位随机字符串；AP_FRONTEND_URL 填当前访问地址——如果用域名反代，必须写 HTTPS 域名，否则 OAuth 回调会失败。浏览器打开 http://localhost:8080，注册的第一个账号即为管理员。之后新建一个 Flow 并进入编辑器，能正常保存流程即安装验证通过。如果不想自托管，跳过本节，直接在 cloud.activepieces.com 注册即可。

# docker-compose.ymlservices:  activepieces:    image: ghcr.io/activepieces/activepieces:latest    ports:      - "8080:80"    environment:      AP_DATABASE_POSTGRES_URL: "postgresql://postgres:postgres@postgres:5432/activepieces?sslmode=disable"      AP_JWT_SECRET: change-me-please      AP_ENCRYPTION_KEY: your-encryption-key-at-least-16-chars      AP_FRONTEND_URL: http://localhost:8080    volumes:      - ap_data:/usr/src/app/dist/packages/server/.activepieces    depends_on:      - postgres  postgres:    image: postgres:14    environment:      POSTGRES_DB: activepieces      POSTGRES_USER: postgres      POSTGRES_PASSWORD: postgres    volumes:      - postgres_data:/var/lib/postgresql/datavolumes:  ap_data:  postgres_data:

docker compose up -d    # 首次拉取镜像并启动docker compose ps       # 查看 postgres 与 activepieces 两个服务状态

快速上手：15 分钟跑通第一个自动化 Flow

最小可用流程不需要先接任何外部 SaaS：用 Webhook 触发器接收 HTTP 请求，用 Code 步骤清洗数据，再用 HTTP Request 动作转发到目标地址——整个过程在编辑器里点选完成，验证零成本。操作顺序如下：

1. 登录后进入默认项目，点击「+ New Flow」，命名「webhook-demo」，保存。

2. 在触发器面板选择「Webhook」，复制自动生成的 Webhook URL。

3. 添加「Code」动作步骤，粘贴一段 JavaScript，把请求体中的 message 字段转成大写并返回。

4. 再添加「HTTP Request」动作，点击输入框旁的「+」图标，从上一节点的测试数据中选择字段完成映射。

5. 点击「Test flow」进入测试模式，在终端用 curl 向 Webhook URL 发一条消息，回到编辑器检查每一步的输入与输出。

6. 确认无误后点击「Publish」发布，之后每次请求都会触发真实执行。

测试成功后，在 Runs 页面可以看到每次执行的输入、输出与耗时，失败步骤能直接看到日志。进阶技巧：在 Code 步骤之后插入 OpenAI 连接器生成摘要，再加一个「人工审批」步骤，审批通过后写入数据库——这就是一个带人在环的 AI 内容管线；把触发器换成 Cron，它就变成一个定时任务。

# 测试 Webhook 触发器（URL 替换为编辑器里复制的完整地址）curl -X POST https://<你的 Webhook URL> \  -H "Content-Type: application/json" \  -d '{"message":"hello activepieces"}'

核心能力详解：4 大支柱

支柱一：Flow 可视化编排。流程由触发器与动作组成，支持分支（Branch）、循环（Loop）和数据映射（Data Mapping）——映射时点选上一节点的测试数据即可填充字段。每个流程有独立版本，可回滚、可导出/导入 JSON，便于作为代码资产纳入 Git。判断、循环、调用这类传统脚本逻辑，可以全部图形化，并对业务人员可见。

支柱二：连接器生态（Connectors/Pieces）。提供 200+ 官方连接器，分为触发器与动作两类，覆盖 Slack、Google Sheets、Airtable、HubSpot、OpenAI、Gemini、Pinecone 等；OAuth/API Key 等授权信息加密存储在数据库中。连接器本身是开源的 TypeScript 模块，可自行扩展或 fork 官方实现，任何未接入的服务都可以用 Webhook 或 HTTP Request 步骤兜底。

支柱三：触发器与执行引擎。支持 Webhook、定时调度（Cron）、SaaS 事件轮询三类核心触发方式。执行引擎负责并发、队列与失败重试：默认使用 PostgreSQL 作为队列，流量大时可切换 Redis 队列（官方文档提供对应环境变量）提升吞吐。代码步骤在隔离的沙箱环境中执行，避免影响主进程稳定性。

支柱四：可观测性与人在环审批。每次运行生成 Run 记录，逐步骤展示输入、输出与耗时，失败步骤可重试或查看日志。「Human-in-the-loop」审批步骤会让流程暂停，等待指定人员在审批页面批准或拒绝后继续。这套能力让 AI 流程（如自动生成内容、批量外呼）在关键节点保留人工把关，是生产可用的核心。

生产部署与监控：从上线到运维

部署方式一：Docker Compose 单机。上面的 Compose 配置足够支撑小团队（数百次/日执行）。生产要点：固定镜像版本 tag，不要长期跟随 latest；升级前备份 PostgreSQL 数据库与 ap_data 数据卷，因为 0.x 版本的数据库迁移不一定向后兼容；前面挂 Caddy 或 Nginx 终结 HTTPS，并把 AP_FRONTEND_URL 改为域名；为 PostgreSQL 配置每日备份与保留策略。

部署方式二：官方云与企业版。不想运维就使用 Activepieces Cloud，官方负责版本升级与基础设施；企业版提供 SSO（SAML）、审计日志、RBAC 等团队治理能力。混合策略常见：开发环境用自托管，生产用云版（或反之），Flow 通过 JSON 导入导出在两者间迁移。

可观测性：产品内看 Runs 页面，检查每步出入参与失败日志；系统层用 docker compose logs -f activepieces 查看服务日志，监控容器 CPU/内存与 PostgreSQL 连接数。对关键流程，建议在流程末尾接一个失败通知动作（Slack 或邮件），把执行失败第一时间推送给值班人，并关注执行延迟与失败率两个核心指标。

<p class="para-label">避坑清单：</p>

<ul class="dash-list"><li>坑 1：AP_ENCRYPTION_KEY 与 AP_JWT_SECRET 必须显式设置并长期保持不变，容器重建后若丢失或改动，已保存的连接器授权将无法解密，需要全部重新连接。</li><li>坑 2：生产环境固定镜像版本 tag，升级前先在测试环境跑一遍迁移；0.x 版本迭代快，直接追 latest 极易因数据库迁移不兼容而升级失败。</li><li>坑 3：公网部署必须做 HTTPS 反代，且访问域名与 AP_FRONTEND_URL 保持一致，否则 OAuth 连接授权时会因回调地址不匹配而失败。</li><li>坑 4：大量使用轮询型触发器时要关注目标服务的 API 限流，触发频率建议设为目标服务配额的一半以下，并为关键步骤开启失败重试。</li></ul>

AI 应用场景

常见误区

面试题

参考来源

• webpageActivepieces 官方网站产品介绍、定价与 Cloud 注册入口