别把 n8n 当 Zapier 用高并发、超时、失败重试生产环境的 5 个翻车现场【免费下载链接】n8nFair-code workflow automation platform with native AI capabilities. Combine visual building with custom code, self-host or cloud, 400 integrations.项目地址: https://gitcode.com/GitHub_Trending/n8/n8n当你第一次在编辑器里拖出几个节点、连上一条 Webhook 链路跑通第一个自动化时n8n 给你的体验和 Zapier 几乎一模一样填个地址、配个动作、点下保存剩下的交给平台。这种感觉会持续到生产环境的第一个流量高峰。真实世界的 n8n 是一个自带完整工作流引擎、任务队列Bull Redis和分布式 Worker 体系的工程系统它的默认配置是为开箱即用服务的而不是为高并发下不出事服务的。本文不写入门教程直接基于 n8n 仓库的真实源码拆解 5 个在生产环境最容易踩的翻车现场以及每一处对应的配置位和代码依据。翻车现场一默认模式下你的 Webhook 没有并发保护很多团队把 n8n 跑在单机上用EXECUTIONS_MODE默认的regular模式进程内直接执行跑生产流量。此时如果外部系统一次性推送大量 Webhookn8n 会怎么表现看配置定义executions.config.ts 中明确写着模式只有两种regular进程内和queue队列模式。Regular 模式下一次触发就在主进程内同步执行多个 Webhook 请求会共享同一进程的事件循环和 CPU。官方为这个场景准备的护栏是N8N_CONCURRENCY_PRODUCTION_LIMIT它只作用于 regular 模式。看 concurrency-control.service.ts 的实现服务内部维护一个容量计数器webhook、trigger、chat三种触发方式共享同一条生产队列getQueue方法中三者都返回queues.get(production)一旦并发超过上限后续执行被ConcurrencyQueue挂起直到前面的执行release释放容量见 concurrency-queue.ts 的enqueue/dequeue逻辑。但真正的坑在于默认值是 -1无限。也就是说你不显式设置这个变量生产环境就没有任何并发闸门流量一上来就是无节制的并发执行。更隐蔽的问题是这条生产队列只存在于单个 n8n 主进程内部一旦你部署了多个副本每个进程各有一份独立的容量计数器并发上限形同虚设。所以 regular 模式只适合验证和小流量想要真正的并发治理必须切换到队列模式。翻车现场二超时默认无限卡死的节点没有救世主比并发更致命的是超时。看 executions.config.ts 中ExecutionsConfig的默认值timeout: number -1; // EXECUTIONS_TIMEOUT-1 表示不限时 maxTimeout: number 3600; // EXECUTIONS_TIMEOUT_MAX上限 1 小时EXECUTIONS_TIMEOUT默认是-1即不设超时。源码注释甚至直白地写道Currently unlimited by default - this default will change in a future version当前默认不限时未来版本会更改。也就是说一个调用了外部 API 的 HTTP Request 节点如果迟迟得不到响应整条工作流可以无限期占用 Worker 资源。更深的坑在引擎层面。JobProcessor 的源码注释揭示了一个关键限制引擎只会在节点与节点之间检查executionTimeoutTimestamp无法中断一个卡在节点内部的执行——比如一次挂起的 HTTP 调用。为此 Worker 侧专门加了一个 watchdog 定时器来强制取消超时任务见 job-processor.ts// The engine only checks executionTimeoutTimestamp between node executions, so it cannot // interrupt a node stuck mid-execution (e.g. a hanging HTTP call). This watchdog cancels // the job for abort-aware operations, mirroring the regular-process timeout... const clearTimeoutWatchdog executionTimeoutTimestamp ! undefined ? scheduleAt(executionTimeoutTimestamp, () this.cancelJob(job.id, timeout)) : undefined;但注意前提watchdog 只在executionTimeoutTimestamp ! undefined时才会安装而这取决于你在工作流设置里配了executionTimeout或全局EXECUTIONS_TIMEOUT。默认无限时 没有 watchdog 一个卡死的 HTTP 节点可以占死 Worker 槽位。另一个超时陷阱在 HTTP Request 节点内部。V3 版本的节点默认超时是 5 分钟300 秒见 HttpRequestV3.node.tsif (timeout) { requestOptions.timeout timeout; } else { // set default timeout to 5 minutes requestOptions.timeout 300_000; }而 V2 版本默认是 1 小时3600000ms见 HttpRequestV2.node.ts。不同版本节点默认超时不同升级后行为可能突变——这种版本差异在排查超时问题时极容易迷惑人。翻车现场三队列模式不是无限并发Worker 并发上限会被卡脖子很多人以为切到EXECUTIONS_MODEqueue、加上 Redis 就算高并发就绪了。但队列模式的并发能力实际上由 Worker 数量和每个 Worker 的并发参数共同决定而且有一处容易被忽略的默认值。看 worker.tsconst flagsSchema z.object({ concurrency: z.number().int().default(10).describe(How many jobs can run in parallel.), });Worker 的--concurrency默认是 10。取值优先级上N8N_CONCURRENCY_PRODUCTION_LIMIT环境变量非 -1 时优先于命令行 flag。更值得注意的是一段警告逻辑if (this.concurrency 5) { this.logger.warn( Concurrency is set to less than 5. THIS CAN LEAD TO AN UNSTABLE ENVIRONMENT. Please consider increasing it to at least 5 to make best use of the worker., ); }并发低于 5 直接警告会导致不稳定环境。也就是说你在容器里裸跑n8n worker单 Worker 只有 10 个并发槽位压测时你以为上了队列就无限扩容实际吞吐被 Worker 数和并发数双重锁死。扩容的正确姿势是加 Worker 副本而不是只指望队列。另一个队列模式的坑是任务卡死与停滞任务stalled job检测。配置中QUEUE_WORKER_LOCK_DURATION默认 1 分钟、QUEUE_WORKER_STALLED_INTERVAL默认 30 秒scaling-mode.config.tsBull 会周期性扫描长时间没有续期的任务。如果任务执行超过锁租约且未及时续约会被判为 stalled。而 n8n 在创建队列时特意设置了maxStalledCount: 0scaling.service.ts含义是禁用 Bull 对停滞任务的隐式重试——任务一旦被判死就直接失败不会自动重跑。翻车现场四失败重试的三不管地带说到重试这是最容易被 Zapier 思维误导的地方。Zapier 式的重试是平台层面的失败了自动再试几次而 n8n 的失败处理分散在三层每一层都有自己的语义组合起来常常让人困惑。第一层节点失败。HTTP Request 节点的失败处理默认是直接抛错中断节点选项里的neverErrorV3 中为response.response.neverError只能控制把非 2xx 响应当作数据而非错误——见 HttpRequestV3.node.ts 中的requestOptions.simple false它并不会触发自动重试。想要自动重试 N 次 退避必须在节点外层自己搭比如用 Loop 或 Split In Batches 循环包裹n8n 没有 Zapier 那种一键全局重试开关。第二层执行级失败。队列模式下执行失败后结果通过job-failed消息回传给主实例任务本身被标记失败不会自动重新入队。源码里甚至明确注释了为什么要防双重重试见 job-processor.ts/** * Bulls implicit retry mechanism and n8ns execution recovery mechanism may * cause a crashed execution to be enqueued. We refrain from processing it, * until we have reworked both mechanisms to prevent this scenario. */ if (execution.status crashed) return { success: false };也就是说Worker 收到一个已标记为crashed的执行时直接拒绝处理——崩溃恢复和 Bull 重试机制本身就可能产生重复入队n8n 选择的是跳过而不是重跑。第三层错误处理工作流。n8n 的正确姿势是每个工作流设置errorWorkflow配合 ErrorTrigger 节点 兜底失败时不是静默重试而是把错误数据路由到告警/补偿流程。这是和 Zapier 思维差异最大的一点——n8n 期望你显式设计失败路径而不是依赖平台替你重试。翻车现场五数据、清理与队列恢复的默认陷阱最后一个翻车点不在执行路径上而在数据与运维侧生产事故往往从这里引爆。执行数据保存。EXECUTIONS_DATA_SAVE_ON_ERROR和EXECUTIONS_DATA_SAVE_ON_SUCCESS默认都是all意味着每次执行的所有节点输入输出都会落库。高并发场景下这会让数据库写入量爆炸。社区里最常见的生产事故就是几百上千的并发跑了一天后数据库被 execution_data 撑爆UI 卡死。可以按需改为none或使用EXECUTIONS_DATA_SAVE_ON_PROGRESS控制中间态保存全部配置定义见 executions.config.ts。数据清理。EXECUTIONS_DATA_PRUNE默认开启EXECUTIONS_DATA_MAX_AGE默认 336 小时14 天EXECUTIONS_DATA_PRUNE_MAX_COUNT默认保留 10000 条。看起来有清理但如果你改了保存策略又忘了调这些值或者关闭了 prune执行表就会无限膨胀。软删除与硬删除的间隔EXECUTIONS_DATA_PRUNE_HARD_DELETE_INTERVAL默认 15 分钟也要心里有数。Redis 中的任务保留。N8N_EXECUTIONS_QUEUE_KEEP_LAST_COMPLETED和N8N_EXECUTIONS_QUEUE_KEEP_LAST_FAILED默认都是 0——即任务完成后立即从 Redis 删除。这带来一个连锁后果想用 Bull 的界面查看最近失败的任务看不到因为默认不留。而如果调大这两个值又要警惕 Redis 内存膨胀每个任务在队列中会有多份拷贝。源码实现见 scaling.service.ts 的addJobconst jobOptions: JobOptions { priority, removeOnComplete: keepLastCompleted, removeOnFail: keepLastFailed, };队列恢复queue recovery。n8n 每 3 小时N8N_EXECUTIONS_QUEUE_RECOVERY_INTERVAL默认 180 分钟会执行一次恢复扫描把数据库中状态为new/running、但队列里已经找不到的执行标记为crashed见 scaling.service.ts 的recoverFromQueue。这意味着什么当 Worker 被kill -9或容器被 OOM 杀掉时正在跑的执行不会自动重试而是被标记为 crashed。配合上一节的maxStalledCount: 0没有任何一层会自动重放丢失的任务——如果业务要求不丢消息你需要自己在触发端如 Redis Stream、消息队列做幂等与重投。生产环境调优清单把上面五个翻车现场收敛成一张可以直接执行的检查清单模式与并发生产流量切EXECUTIONS_MODEqueue按业务压测结果给 Worker 设置--concurrency或N8N_CONCURRENCY_PRODUCTION_LIMIT不要低于 5必要时横向加 Workerregular 模式下务必显式设置并发上限并接受多副本时上限不共享的限制。超时全局设置EXECUTIONS_TIMEOUT建议 300 秒以内注意EXECUTIONS_TIMEOUT_MAX是硬上限同时在工作流 Settings 里设置executionTimeout覆盖特定工作流给外部调用配好 HTTP Request 节点的 timeout别依赖 5 分钟/1 小时的节点默认值。失败路径放弃平台自动重试的预期为每个关键工作流配置errorWorkflow Error Trigger 节点做告警与补偿对关键外部调用显式设计带退避的重试逻辑接受crashed 任务不会被自动重跑这一现实。数据与资源按业务把EXECUTIONS_DATA_SAVE_ON_SUCCESS/ERROR调为none或只在关键工作流保存配合EXECUTIONS_DATA_MAX_AGE、EXECUTIONS_DATA_PRUNE_MAX_COUNT控制执行表体积N8N_EXECUTIONS_QUEUE_KEEP_LAST_COMPLETED/FAILED调大前先评估 Redis 内存给 Worker 设置QUEUE_HEALTH_CHECK_ACTIVE并接入/healthz与/healthz/readiness探针。监控开启N8N_GRACEFUL_SHUTDOWN_TIMEOUT优雅停机避免容器滚动更新时大量执行被打成 crashed关注队列恢复扫描日志中danglingIds的数量——它直接反映丢任务事件的频率。n8n 最大的优势从来不是像 Zapier 一样开箱即用而是当你愿意下潜到EXECUTIONS_TIMEOUT、maxStalledCount: 0、ConcurrencyControlService这一层时它能给你完整的、可预测的工程控制力。这套分布式工作流骨架由 worker.ts、job-processor.ts、scaling.service.ts 共同构成它们值得每一个把 n8n 放进生产环境的团队通读一遍——毕竟翻车不可怕可怕的是翻车了还不知道默认配置替你做了哪些决定。【免费下载链接】n8nFair-code workflow automation platform with native AI capabilities. Combine visual building with custom code, self-host or cloud, 400 integrations.项目地址: https://gitcode.com/GitHub_Trending/n8/n8n创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考
别把 n8n 当 Zapier 用高并发、超时、失败重试生产环境的 5 个翻车现场【免费下载链接】n8nFair-code workflow automation platform with native AI capabilities. Combine visual building with custom code, self-host or cloud, 400 integrations.项目地址: https://gitcode.com/GitHub_Trending/n8/n8n当你第一次在编辑器里拖出几个节点、连上一条 Webhook 链路跑通第一个自动化时n8n 给你的体验和 Zapier 几乎一模一样填个地址、配个动作、点下保存剩下的交给平台。这种感觉会持续到生产环境的第一个流量高峰。真实世界的 n8n 是一个自带完整工作流引擎、任务队列Bull Redis和分布式 Worker 体系的工程系统它的默认配置是为开箱即用服务的而不是为高并发下不出事服务的。本文不写入门教程直接基于 n8n 仓库的真实源码拆解 5 个在生产环境最容易踩的翻车现场以及每一处对应的配置位和代码依据。翻车现场一默认模式下你的 Webhook 没有并发保护很多团队把 n8n 跑在单机上用EXECUTIONS_MODE默认的regular模式进程内直接执行跑生产流量。此时如果外部系统一次性推送大量 Webhookn8n 会怎么表现看配置定义executions.config.ts 中明确写着模式只有两种regular进程内和queue队列模式。Regular 模式下一次触发就在主进程内同步执行多个 Webhook 请求会共享同一进程的事件循环和 CPU。官方为这个场景准备的护栏是N8N_CONCURRENCY_PRODUCTION_LIMIT它只作用于 regular 模式。看 concurrency-control.service.ts 的实现服务内部维护一个容量计数器webhook、trigger、chat三种触发方式共享同一条生产队列getQueue方法中三者都返回queues.get(production)一旦并发超过上限后续执行被ConcurrencyQueue挂起直到前面的执行release释放容量见 concurrency-queue.ts 的enqueue/dequeue逻辑。但真正的坑在于默认值是 -1无限。也就是说你不显式设置这个变量生产环境就没有任何并发闸门流量一上来就是无节制的并发执行。更隐蔽的问题是这条生产队列只存在于单个 n8n 主进程内部一旦你部署了多个副本每个进程各有一份独立的容量计数器并发上限形同虚设。所以 regular 模式只适合验证和小流量想要真正的并发治理必须切换到队列模式。翻车现场二超时默认无限卡死的节点没有救世主比并发更致命的是超时。看 executions.config.ts 中ExecutionsConfig的默认值timeout: number -1; // EXECUTIONS_TIMEOUT-1 表示不限时 maxTimeout: number 3600; // EXECUTIONS_TIMEOUT_MAX上限 1 小时EXECUTIONS_TIMEOUT默认是-1即不设超时。源码注释甚至直白地写道Currently unlimited by default - this default will change in a future version当前默认不限时未来版本会更改。也就是说一个调用了外部 API 的 HTTP Request 节点如果迟迟得不到响应整条工作流可以无限期占用 Worker 资源。更深的坑在引擎层面。JobProcessor 的源码注释揭示了一个关键限制引擎只会在节点与节点之间检查executionTimeoutTimestamp无法中断一个卡在节点内部的执行——比如一次挂起的 HTTP 调用。为此 Worker 侧专门加了一个 watchdog 定时器来强制取消超时任务见 job-processor.ts// The engine only checks executionTimeoutTimestamp between node executions, so it cannot // interrupt a node stuck mid-execution (e.g. a hanging HTTP call). This watchdog cancels // the job for abort-aware operations, mirroring the regular-process timeout... const clearTimeoutWatchdog executionTimeoutTimestamp ! undefined ? scheduleAt(executionTimeoutTimestamp, () this.cancelJob(job.id, timeout)) : undefined;但注意前提watchdog 只在executionTimeoutTimestamp ! undefined时才会安装而这取决于你在工作流设置里配了executionTimeout或全局EXECUTIONS_TIMEOUT。默认无限时 没有 watchdog 一个卡死的 HTTP 节点可以占死 Worker 槽位。另一个超时陷阱在 HTTP Request 节点内部。V3 版本的节点默认超时是 5 分钟300 秒见 HttpRequestV3.node.tsif (timeout) { requestOptions.timeout timeout; } else { // set default timeout to 5 minutes requestOptions.timeout 300_000; }而 V2 版本默认是 1 小时3600000ms见 HttpRequestV2.node.ts。不同版本节点默认超时不同升级后行为可能突变——这种版本差异在排查超时问题时极容易迷惑人。翻车现场三队列模式不是无限并发Worker 并发上限会被卡脖子很多人以为切到EXECUTIONS_MODEqueue、加上 Redis 就算高并发就绪了。但队列模式的并发能力实际上由 Worker 数量和每个 Worker 的并发参数共同决定而且有一处容易被忽略的默认值。看 worker.tsconst flagsSchema z.object({ concurrency: z.number().int().default(10).describe(How many jobs can run in parallel.), });Worker 的--concurrency默认是 10。取值优先级上N8N_CONCURRENCY_PRODUCTION_LIMIT环境变量非 -1 时优先于命令行 flag。更值得注意的是一段警告逻辑if (this.concurrency 5) { this.logger.warn( Concurrency is set to less than 5. THIS CAN LEAD TO AN UNSTABLE ENVIRONMENT. Please consider increasing it to at least 5 to make best use of the worker., ); }并发低于 5 直接警告会导致不稳定环境。也就是说你在容器里裸跑n8n worker单 Worker 只有 10 个并发槽位压测时你以为上了队列就无限扩容实际吞吐被 Worker 数和并发数双重锁死。扩容的正确姿势是加 Worker 副本而不是只指望队列。另一个队列模式的坑是任务卡死与停滞任务stalled job检测。配置中QUEUE_WORKER_LOCK_DURATION默认 1 分钟、QUEUE_WORKER_STALLED_INTERVAL默认 30 秒scaling-mode.config.tsBull 会周期性扫描长时间没有续期的任务。如果任务执行超过锁租约且未及时续约会被判为 stalled。而 n8n 在创建队列时特意设置了maxStalledCount: 0scaling.service.ts含义是禁用 Bull 对停滞任务的隐式重试——任务一旦被判死就直接失败不会自动重跑。翻车现场四失败重试的三不管地带说到重试这是最容易被 Zapier 思维误导的地方。Zapier 式的重试是平台层面的失败了自动再试几次而 n8n 的失败处理分散在三层每一层都有自己的语义组合起来常常让人困惑。第一层节点失败。HTTP Request 节点的失败处理默认是直接抛错中断节点选项里的neverErrorV3 中为response.response.neverError只能控制把非 2xx 响应当作数据而非错误——见 HttpRequestV3.node.ts 中的requestOptions.simple false它并不会触发自动重试。想要自动重试 N 次 退避必须在节点外层自己搭比如用 Loop 或 Split In Batches 循环包裹n8n 没有 Zapier 那种一键全局重试开关。第二层执行级失败。队列模式下执行失败后结果通过job-failed消息回传给主实例任务本身被标记失败不会自动重新入队。源码里甚至明确注释了为什么要防双重重试见 job-processor.ts/** * Bulls implicit retry mechanism and n8ns execution recovery mechanism may * cause a crashed execution to be enqueued. We refrain from processing it, * until we have reworked both mechanisms to prevent this scenario. */ if (execution.status crashed) return { success: false };也就是说Worker 收到一个已标记为crashed的执行时直接拒绝处理——崩溃恢复和 Bull 重试机制本身就可能产生重复入队n8n 选择的是跳过而不是重跑。第三层错误处理工作流。n8n 的正确姿势是每个工作流设置errorWorkflow配合 ErrorTrigger 节点 兜底失败时不是静默重试而是把错误数据路由到告警/补偿流程。这是和 Zapier 思维差异最大的一点——n8n 期望你显式设计失败路径而不是依赖平台替你重试。翻车现场五数据、清理与队列恢复的默认陷阱最后一个翻车点不在执行路径上而在数据与运维侧生产事故往往从这里引爆。执行数据保存。EXECUTIONS_DATA_SAVE_ON_ERROR和EXECUTIONS_DATA_SAVE_ON_SUCCESS默认都是all意味着每次执行的所有节点输入输出都会落库。高并发场景下这会让数据库写入量爆炸。社区里最常见的生产事故就是几百上千的并发跑了一天后数据库被 execution_data 撑爆UI 卡死。可以按需改为none或使用EXECUTIONS_DATA_SAVE_ON_PROGRESS控制中间态保存全部配置定义见 executions.config.ts。数据清理。EXECUTIONS_DATA_PRUNE默认开启EXECUTIONS_DATA_MAX_AGE默认 336 小时14 天EXECUTIONS_DATA_PRUNE_MAX_COUNT默认保留 10000 条。看起来有清理但如果你改了保存策略又忘了调这些值或者关闭了 prune执行表就会无限膨胀。软删除与硬删除的间隔EXECUTIONS_DATA_PRUNE_HARD_DELETE_INTERVAL默认 15 分钟也要心里有数。Redis 中的任务保留。N8N_EXECUTIONS_QUEUE_KEEP_LAST_COMPLETED和N8N_EXECUTIONS_QUEUE_KEEP_LAST_FAILED默认都是 0——即任务完成后立即从 Redis 删除。这带来一个连锁后果想用 Bull 的界面查看最近失败的任务看不到因为默认不留。而如果调大这两个值又要警惕 Redis 内存膨胀每个任务在队列中会有多份拷贝。源码实现见 scaling.service.ts 的addJobconst jobOptions: JobOptions { priority, removeOnComplete: keepLastCompleted, removeOnFail: keepLastFailed, };队列恢复queue recovery。n8n 每 3 小时N8N_EXECUTIONS_QUEUE_RECOVERY_INTERVAL默认 180 分钟会执行一次恢复扫描把数据库中状态为new/running、但队列里已经找不到的执行标记为crashed见 scaling.service.ts 的recoverFromQueue。这意味着什么当 Worker 被kill -9或容器被 OOM 杀掉时正在跑的执行不会自动重试而是被标记为 crashed。配合上一节的maxStalledCount: 0没有任何一层会自动重放丢失的任务——如果业务要求不丢消息你需要自己在触发端如 Redis Stream、消息队列做幂等与重投。生产环境调优清单把上面五个翻车现场收敛成一张可以直接执行的检查清单模式与并发生产流量切EXECUTIONS_MODEqueue按业务压测结果给 Worker 设置--concurrency或N8N_CONCURRENCY_PRODUCTION_LIMIT不要低于 5必要时横向加 Workerregular 模式下务必显式设置并发上限并接受多副本时上限不共享的限制。超时全局设置EXECUTIONS_TIMEOUT建议 300 秒以内注意EXECUTIONS_TIMEOUT_MAX是硬上限同时在工作流 Settings 里设置executionTimeout覆盖特定工作流给外部调用配好 HTTP Request 节点的 timeout别依赖 5 分钟/1 小时的节点默认值。失败路径放弃平台自动重试的预期为每个关键工作流配置errorWorkflow Error Trigger 节点做告警与补偿对关键外部调用显式设计带退避的重试逻辑接受crashed 任务不会被自动重跑这一现实。数据与资源按业务把EXECUTIONS_DATA_SAVE_ON_SUCCESS/ERROR调为none或只在关键工作流保存配合EXECUTIONS_DATA_MAX_AGE、EXECUTIONS_DATA_PRUNE_MAX_COUNT控制执行表体积N8N_EXECUTIONS_QUEUE_KEEP_LAST_COMPLETED/FAILED调大前先评估 Redis 内存给 Worker 设置QUEUE_HEALTH_CHECK_ACTIVE并接入/healthz与/healthz/readiness探针。监控开启N8N_GRACEFUL_SHUTDOWN_TIMEOUT优雅停机避免容器滚动更新时大量执行被打成 crashed关注队列恢复扫描日志中danglingIds的数量——它直接反映丢任务事件的频率。n8n 最大的优势从来不是像 Zapier 一样开箱即用而是当你愿意下潜到EXECUTIONS_TIMEOUT、maxStalledCount: 0、ConcurrencyControlService这一层时它能给你完整的、可预测的工程控制力。这套分布式工作流骨架由 worker.ts、job-processor.ts、scaling.service.ts 共同构成它们值得每一个把 n8n 放进生产环境的团队通读一遍——毕竟翻车不可怕可怕的是翻车了还不知道默认配置替你做了哪些决定。【免费下载链接】n8nFair-code workflow automation platform with native AI capabilities. Combine visual building with custom code, self-host or cloud, 400 integrations.项目地址: https://gitcode.com/GitHub_Trending/n8/n8n创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考
