多租户与单租户部署 Activepieces 时怎么选 AP_EXECUTION_MODE 沙箱模式【免费下载链接】activepiecesAI Agents MCPs AI Workflow Automation • (~400 MCP servers for AI agents) • AI Automation / AI Agent with MCPs • AI Workflows AI Agents • MCPs for AI Agents项目地址: https://gitcode.com/GitHub_Trending/ac/activepieces自托管部署 Activepieces 时AP_EXECUTION_MODE是最关键的安全选择流程代码Code step 和 piece action总是运行在一个包裹引擎进程的沙箱里这个环境变量决定选哪种沙箱也就决定了一个恶意或有问题的流程是被限制在单个 worker 内还是能触到内核。文档给出的简化判断标准是多租户多个团队或客户共用一套实例→ 用 V8 / Code SandboxingSANDBOX_CODE_ONLY安全且不需要在 Kubernetes 里给容器开 privileged Docker防止提权通常默认被禁止。单租户内部团队自用→ 用 No SandboxingUNSANDBOXED更快同样不需要 privileged Docker。四种模式的完整对照来自 沙箱模式说明模式支持 Code Piece 用 npm需要 Privileged Docker性能多租户安全可复用 Worker环境变量取值V8/Code Sandboxing否否Fast Lightweight是是AP_EXECUTION_MODESANDBOX_CODE_ONLYNo Sandboxing是否Fast Lightweight否是AP_EXECUTION_MODEUNSANDBOXEDKernel Namespaces Sandboxing是是Slow CPU Intensive是否AP_EXECUTION_MODESANDBOX_PROCESSCombined Sandboxing否是Medium CPU Intensive是是AP_EXECUTION_MODESANDBOX_CODE_AND_PROCESS注意UNSANDBOXED是 环境变量参考 中列出的默认值单租户部署不显式设置时行为就是它但多租户实例必须显式改值。两种模式的隔离机制差别架构文档解释了各模式实际怎么工作这直接影响选型时的代价UNSANDBOXED、SANDBOX_CODE_ONLY引擎以普通child_process.fork启动并带内存上限。SANDBOX_CODE_ONLY下每个 Code step 再套一层全新的isolated-vm上下文每个 isolate 128 MB、移除require、步骤结束后销毁。没有 Linux namespace 机制不需要CAP_SYS_ADMIN不需要 privileged 容器。沙箱在任务之间保持热状态所以执行快。V8 保证用户代码碰不到require、文件系统和别的步骤的内存但如果宿主 Node 进程本身被攻破V8 不能保护各 isolate 互相隔离。SANDBOX_PROCESS、SANDBOX_CODE_AND_PROCESS引擎运行在isolate二进制里每次运行创建全新的 PID、mount、user、UTS namespace并把引擎和代码产物以只读方式挂载。Code step 里用任意 npm 包是安全的代价是每次运行都要冷启动沙箱不可复用且 worker 容器必须持有CAP_SYS_ADMIN——Docker 里是--privilegedKubernetes 里是securityContext.privileged: true。架构文档给了一个 Kubernetes 上的具体例子客户提交了一个恶意 Code step。用SANDBOX_PROCESSworker pod 是 privileged 的内核漏洞逃逸到宿主机后读取 service-account token、调 Kubernetes API、横向打到同集群的其他 pod。影响范围是整个集群。用SANDBOX_CODE_ONLYworker 没有任何特殊 capabilityCode step 在干净的 V8 isolate 里运行没有require、没有文件系统、没有 npm。影响范围是那一个 worker pod。文档同时给了明确警告只有你确实需要在 Code step 里用任意 npm 包时才选SANDBOX_PROCESS并且要放在专用节点池上一个 privileged 的 Activepieces worker 永远不应与无关工作负载共享节点。结论上SANDBOX_CODE_ONLY是唯一同时满足多租户安全且以非特权容器运行的模式也是 Activepieces Cloud 使用的模式适配标准 Kubernetes 安全基线UNSANDBOXED适合单租户自用换取速度和不依赖 npm 之外的无隔离成本。在 Docker Compose 部署中设置Self Host (Docker) 文档给出了设置位置写入安装目录下的.env文件。如果你使用AP_EDITIONee需要同时设置版本和执行模式AP_EDITIONee AP_EXECUTION_MODESANDBOX_CODE_ONLY这里有个容易踩的坑仓库里的.env.example默认携带AP_EXECUTION_MODEUNSANDBOXED而该组合eeUNSANDBOXED会在启动时被服务器直接拒绝。单租户 Community 部署可以保留UNSANDBOXED但 ee 版本不行。生产环境的完整执行配置在 Production Setup 中这些取值就是官方基准测试实测所用的配置AP_WORKER_CONCURRENCY1 AP_REUSE_SANDBOXtrue AP_EXECUTION_MODESANDBOX_CODE_ONLY AP_FILE_STORAGE_LOCATIONS3 AP_S3_USE_SIGNED_URLStrue注意变量落在哪个容器上拆分 app 与 workerSeparate Workers时执行类变量AP_WORKER_CONCURRENCY、AP_REUSE_SANDBOX、AP_EXECUTION_MODE设在worker容器S3 变量设在app容器如果跑的是单容器AP_CONTAINER_TYPEWORKER_AND_APP默认值则全部设在这一个容器上。在 Helm 部署中设置Kubernetes (Helm) 文档要求在 values 文件如my-values.yaml的activepiecesConfig下设置activepiecesConfig: AP_EDITION: ee AP_EXECUTION_MODE: SANDBOX_CODE_ONLY然后helm install activepieces deploy/activepieces-helm -f my-values.yamlHelm 文档强调了一个易错点每个变量只在一个地方设置。activepiecesConfig写的是明文凭据而activepiecesEnvVariables从你自建 Kubernetes secret 里取同名变量、且在渲染顺序上后者优先secret 里的值会覆盖。chart 默认把AP_EDITION和AP_EXECUTION_MODE列在activepieces-config-secrets下所以要么把它们从那里移除要么改为在那个 secret 里设置。AP_EDITIONee搭配默认执行模式会在启动时被拒绝app 起不来。验证配置是否生效文档给出的检查路径按部署方式分两条Docker Composedocker compose -p activepieces ps curl http://localhost:8080/api/v1/health四个容器都应为Uphealth 端点有响应然后登录界面打开Platform Admin → Infrastructure → Workers能看到至少一个 worker 说明 worker 已注册。如果 app 反复重启读启动错误docker compose -p activepieces logs app | grep -i failed to start文档明确列出的一个常见原因就是AP_EXECUTION_MODEUNSANDBOXED搭配AP_EDITIONee在启动时被拒绝改回SANDBOX_CODE_ONLY即可。Helmkubectl get pods kubectl get services kubectl logs deployment/activepieces边界与限制几条影响选型的硬性限制直接来自文档Worker Groups 不支持 Code-only 模式。如果你按 Worker Groups 为特定项目保留专用 worker 容量分组 worker 必须保持AP_EXECUTION_MODESANDBOX_PROCESScode-only 模式会被拒绝Production Setup 文档原文code-only mode is rejected for grouped workers。此时你需要接受 privileged 容器并遵循专用节点池、不与无关负载共享节点的要求。多租户选UNSANDBOXED不成立对照表里 No Sandboxing 的多租户安全列为否且 ee 版本启动时直接拒绝该组合。网络面是另一个维度。执行模式决定用户代码如何运行AP_NETWORK_MODE决定代码能访问到什么STRICT时安装引擎进程内的 SSRF 守卫。选SANDBOX_CODE_ONLY后如果还要收紧出站参见 Network Security它叠加在每种沙箱模式之上不是替代。V8 isolate 的隔离边界是进程内宿主 Node 进程被攻破时它不提供保护这一点架构文档明确列为 V8 不保证的项。按上面的对照表和限制走完选择后多租户实例落到SANDBOX_CODE_ONLY配合AP_EDITIONee、专用节点池问题不存在单租户内部实例落到UNSANDBOXED或需要 npm 时落到SANDBOX_PROCESS并隔离到专用节点池再用 Workers 页面和启动日志确认配置已生效。【免费下载链接】activepiecesAI Agents MCPs AI Workflow Automation • (~400 MCP servers for AI agents) • AI Automation / AI Agent with MCPs • AI Workflows AI Agents • MCPs for AI Agents项目地址: https://gitcode.com/GitHub_Trending/ac/activepieces创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考 多租户与单租户部署 Activepieces 时怎么选 AP_EXECUTION_MODE 沙箱模式？
多租户与单租户部署 Activepieces 时怎么选 AP_EXECUTION_MODE 沙箱模式【免费下载链接】activepiecesAI Agents MCPs AI Workflow Automation • (~400 MCP servers for AI agents) • AI Automation / AI Agent with MCPs • AI Workflows AI Agents • MCPs for AI Agents项目地址: https://gitcode.com/GitHub_Trending/ac/activepieces自托管部署 Activepieces 时AP_EXECUTION_MODE是最关键的安全选择流程代码Code step 和 piece action总是运行在一个包裹引擎进程的沙箱里这个环境变量决定选哪种沙箱也就决定了一个恶意或有问题的流程是被限制在单个 worker 内还是能触到内核。文档给出的简化判断标准是多租户多个团队或客户共用一套实例→ 用 V8 / Code SandboxingSANDBOX_CODE_ONLY安全且不需要在 Kubernetes 里给容器开 privileged Docker防止提权通常默认被禁止。单租户内部团队自用→ 用 No SandboxingUNSANDBOXED更快同样不需要 privileged Docker。四种模式的完整对照来自 沙箱模式说明模式支持 Code Piece 用 npm需要 Privileged Docker性能多租户安全可复用 Worker环境变量取值V8/Code Sandboxing否否Fast Lightweight是是AP_EXECUTION_MODESANDBOX_CODE_ONLYNo Sandboxing是否Fast Lightweight否是AP_EXECUTION_MODEUNSANDBOXEDKernel Namespaces Sandboxing是是Slow CPU Intensive是否AP_EXECUTION_MODESANDBOX_PROCESSCombined Sandboxing否是Medium CPU Intensive是是AP_EXECUTION_MODESANDBOX_CODE_AND_PROCESS注意UNSANDBOXED是 环境变量参考 中列出的默认值单租户部署不显式设置时行为就是它但多租户实例必须显式改值。两种模式的隔离机制差别架构文档解释了各模式实际怎么工作这直接影响选型时的代价UNSANDBOXED、SANDBOX_CODE_ONLY引擎以普通child_process.fork启动并带内存上限。SANDBOX_CODE_ONLY下每个 Code step 再套一层全新的isolated-vm上下文每个 isolate 128 MB、移除require、步骤结束后销毁。没有 Linux namespace 机制不需要CAP_SYS_ADMIN不需要 privileged 容器。沙箱在任务之间保持热状态所以执行快。V8 保证用户代码碰不到require、文件系统和别的步骤的内存但如果宿主 Node 进程本身被攻破V8 不能保护各 isolate 互相隔离。SANDBOX_PROCESS、SANDBOX_CODE_AND_PROCESS引擎运行在isolate二进制里每次运行创建全新的 PID、mount、user、UTS namespace并把引擎和代码产物以只读方式挂载。Code step 里用任意 npm 包是安全的代价是每次运行都要冷启动沙箱不可复用且 worker 容器必须持有CAP_SYS_ADMIN——Docker 里是--privilegedKubernetes 里是securityContext.privileged: true。架构文档给了一个 Kubernetes 上的具体例子客户提交了一个恶意 Code step。用SANDBOX_PROCESSworker pod 是 privileged 的内核漏洞逃逸到宿主机后读取 service-account token、调 Kubernetes API、横向打到同集群的其他 pod。影响范围是整个集群。用SANDBOX_CODE_ONLYworker 没有任何特殊 capabilityCode step 在干净的 V8 isolate 里运行没有require、没有文件系统、没有 npm。影响范围是那一个 worker pod。文档同时给了明确警告只有你确实需要在 Code step 里用任意 npm 包时才选SANDBOX_PROCESS并且要放在专用节点池上一个 privileged 的 Activepieces worker 永远不应与无关工作负载共享节点。结论上SANDBOX_CODE_ONLY是唯一同时满足多租户安全且以非特权容器运行的模式也是 Activepieces Cloud 使用的模式适配标准 Kubernetes 安全基线UNSANDBOXED适合单租户自用换取速度和不依赖 npm 之外的无隔离成本。在 Docker Compose 部署中设置Self Host (Docker) 文档给出了设置位置写入安装目录下的.env文件。如果你使用AP_EDITIONee需要同时设置版本和执行模式AP_EDITIONee AP_EXECUTION_MODESANDBOX_CODE_ONLY这里有个容易踩的坑仓库里的.env.example默认携带AP_EXECUTION_MODEUNSANDBOXED而该组合eeUNSANDBOXED会在启动时被服务器直接拒绝。单租户 Community 部署可以保留UNSANDBOXED但 ee 版本不行。生产环境的完整执行配置在 Production Setup 中这些取值就是官方基准测试实测所用的配置AP_WORKER_CONCURRENCY1 AP_REUSE_SANDBOXtrue AP_EXECUTION_MODESANDBOX_CODE_ONLY AP_FILE_STORAGE_LOCATIONS3 AP_S3_USE_SIGNED_URLStrue注意变量落在哪个容器上拆分 app 与 workerSeparate Workers时执行类变量AP_WORKER_CONCURRENCY、AP_REUSE_SANDBOX、AP_EXECUTION_MODE设在worker容器S3 变量设在app容器如果跑的是单容器AP_CONTAINER_TYPEWORKER_AND_APP默认值则全部设在这一个容器上。在 Helm 部署中设置Kubernetes (Helm) 文档要求在 values 文件如my-values.yaml的activepiecesConfig下设置activepiecesConfig: AP_EDITION: ee AP_EXECUTION_MODE: SANDBOX_CODE_ONLY然后helm install activepieces deploy/activepieces-helm -f my-values.yamlHelm 文档强调了一个易错点每个变量只在一个地方设置。activepiecesConfig写的是明文凭据而activepiecesEnvVariables从你自建 Kubernetes secret 里取同名变量、且在渲染顺序上后者优先secret 里的值会覆盖。chart 默认把AP_EDITION和AP_EXECUTION_MODE列在activepieces-config-secrets下所以要么把它们从那里移除要么改为在那个 secret 里设置。AP_EDITIONee搭配默认执行模式会在启动时被拒绝app 起不来。验证配置是否生效文档给出的检查路径按部署方式分两条Docker Composedocker compose -p activepieces ps curl http://localhost:8080/api/v1/health四个容器都应为Uphealth 端点有响应然后登录界面打开Platform Admin → Infrastructure → Workers能看到至少一个 worker 说明 worker 已注册。如果 app 反复重启读启动错误docker compose -p activepieces logs app | grep -i failed to start文档明确列出的一个常见原因就是AP_EXECUTION_MODEUNSANDBOXED搭配AP_EDITIONee在启动时被拒绝改回SANDBOX_CODE_ONLY即可。Helmkubectl get pods kubectl get services kubectl logs deployment/activepieces边界与限制几条影响选型的硬性限制直接来自文档Worker Groups 不支持 Code-only 模式。如果你按 Worker Groups 为特定项目保留专用 worker 容量分组 worker 必须保持AP_EXECUTION_MODESANDBOX_PROCESScode-only 模式会被拒绝Production Setup 文档原文code-only mode is rejected for grouped workers。此时你需要接受 privileged 容器并遵循专用节点池、不与无关负载共享节点的要求。多租户选UNSANDBOXED不成立对照表里 No Sandboxing 的多租户安全列为否且 ee 版本启动时直接拒绝该组合。网络面是另一个维度。执行模式决定用户代码如何运行AP_NETWORK_MODE决定代码能访问到什么STRICT时安装引擎进程内的 SSRF 守卫。选SANDBOX_CODE_ONLY后如果还要收紧出站参见 Network Security它叠加在每种沙箱模式之上不是替代。V8 isolate 的隔离边界是进程内宿主 Node 进程被攻破时它不提供保护这一点架构文档明确列为 V8 不保证的项。按上面的对照表和限制走完选择后多租户实例落到SANDBOX_CODE_ONLY配合AP_EDITIONee、专用节点池问题不存在单租户内部实例落到UNSANDBOXED或需要 npm 时落到SANDBOX_PROCESS并隔离到专用节点池再用 Workers 页面和启动日志确认配置已生效。【免费下载链接】activepiecesAI Agents MCPs AI Workflow Automation • (~400 MCP servers for AI agents) • AI Automation / AI Agent with MCPs • AI Workflows AI Agents • MCPs for AI Agents项目地址: https://gitcode.com/GitHub_Trending/ac/activepieces创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考