容器与持久化
官方建议多数自托管场景使用 Docker。必须持久化 /home/node/.n8n；即使改用 PostgreSQL，该目录仍可能包含加密密钥、日志和其他实例数据。
Automation Cluster · 部署要求E0 · 官方公开资料
n8n 自托管要求：上线前要准备什么
自托管不是把 n8n 容器启动起来就结束。真正的决策是：你的团队是否愿意持续负责持久化、数据库、凭证密钥、Webhook、HTTPS、安全、升级、备份和故障恢复。
先说结论
没有明确运维负责人，就不要把“免费自托管”当默认方案
Community Edition 的订阅价格可以是零，但基础设施和工程责任不会消失。只有部署控制、数据边界、复杂扩展或长期总成本确实重要，并且团队能承担运行责任时，自托管才构成优势。
生产清单
五项基础责任缺一不可
数据库与备份
SQLite 是默认值。持续运行或需要扩展的生产实例应评估 PostgreSQL，并分别备份数据库、实例配置和加密密钥；只备份容器镜像不够。
凭证加密密钥
n8n 首次启动会生成密钥，也可显式设置 N8N_ENCRYPTION_KEY。密钥丢失会影响已存凭证；queue mode 的主实例与所有 worker 必须共享同一密钥。
公网 Webhook 与代理
外部触发器需要稳定可访问的 HTTPS 地址。反向代理后应设置 N8N_WEBHOOK_URL、N8N_PROXY_HOPS，并正确传递 Forwarded headers；本地 tunnel 只用于开发测试。
安全与维护责任
需要有人负责 TLS、升级、权限、节点风险、公共 API、执行数据和安全审计。官方明确将自托管推荐给有服务器与应用管理经验的用户。
扩展不是默认要求
什么时候才需要 queue mode
官方将 queue mode 定位为最佳扩展方式：主实例接收触发，Redis 维护队列，worker 执行任务，数据库保存结果。它增加了 Redis、worker、共享密钥、监控和存储设计，不应在单实例尚未证明瓶颈前先上。
- 使用 PostgreSQL，而不是用 SQLite 跑分布式 queue mode。
- 主实例、worker 与 webhook processor 使用同一加密密钥。
- 二进制数据不能在 queue mode 下依赖本地 filesystem；需要单独规划。
- 先记录并发、积压、执行时长和失败恢复，再决定增加 worker。
自托管还是 Cloud
用责任边界做决定，不只比较标价
| 判断问题 | 自托管更合理 | Cloud 更稳妥 |
|---|---|---|
| 为什么自托管？ | 必须控制部署、网络或数据边界 | 只是因为 Community Edition 看起来免费 |
| 谁负责？ | 有明确的运维、安全和恢复负责人 | 没有人负责升级、备份和事故响应 |
| 如何验证？ | 用真实工作流测并发、失败恢复和维护时间 | 仅比较订阅价格和服务器月租 |
官方证据
本页只使用 E0 公开资料
核查日期：2026-10-26。我们没有在你的账户、服务器或真实生产负载中运行 n8n，因此不声称给出了适用于所有工作流的性能或成本基准。
常见问题
自托管 n8n 需要多少内存和 CPU？
n8n 没有为所有工作流给出一个通用的生产最低规格。官方 Docker Compose Assistant 指南的特定沙箱栈写明至少 4 GB RAM 和 2 vCPU，但这不是所有核心 n8n 部署的统一承诺。应按并发、执行时长、二进制数据和 Code/AI 节点做负载测试。
SQLite 适合生产环境吗？
SQLite 是默认数据库，适合试用和较小的单实例场景。官方 Compose 指南建议需要持续运行、超过少量用户或工作流的生产实例改用 PostgreSQL；queue mode 不应使用 SQLite。
自托管 n8n 是否等于零软件成本？
Community Edition 可以免费自托管，但服务器、数据库、备份、监控、升级、故障恢复和工程时间仍有成本；部分协作、治理或扩展能力也依版本和套餐而不同。
什么时候应该直接选择 n8n Cloud？
如果团队没有明确的服务器、安全、备份和升级负责人，或者自托管并不能带来必须的部署控制、数据边界或成本优势，Cloud 通常是更低风险的起点。