先说结论:在 VPS 上自托管 n8n,适合需要连接内部系统、控制工作流数据、长期运行 webhook 或自定义自动化的团队。上线架构不应是“容器直接开放 5678 端口 + 示例账号密码”,而应至少包含固定域名、HTTPS 入口、n8n 用户管理、持久化数据库、独立加密密钥、执行数据清理、备份和监控。接入 OpenAI、Gemini 等 AI 服务时,API 密钥应放进 n8n 凭据库,不写进工作流 JSON、URL 或文章示例。

哪些业务值得自托管 n8n?
| 业务任务 | 自托管的主要价值 | 必须补齐的控制 |
|---|---|---|
| 表单线索分发与 CRM 同步 | 连接自有接口和内部数据 | 去重、幂等、失败队列和人工补偿 |
| 订单、库存、ERP 数据同步 | 按业务规则编排多个系统 | 事务边界、限流、审计和重放 |
| AI 摘要、分类、客服辅助 | 组合模型、知识和内部流程 | 脱敏、预算、人工复核和供应商降级 |
| 告警、日报与运营通知 | 集中定时任务和通知渠道 | 时区、重复通知、静默窗口和升级规则 |
| 文件与批量数据处理 | 靠近数据源并自定义处理 | 临时文件、磁盘增长、超时和恶意文件隔离 |
如果只是个人试用、没有服务器运维能力,托管版可能更省总成本。自托管意味着你负责更新、TLS、账号、凭据、数据库、备份和事故响应。资源估算见n8n 自托管服务器配置指南。
生产可用的 n8n 架构

- 入口:域名、DNS、HTTPS 和反向代理,公网只开放必要的 80/443;
- 应用:固定版本的官方 n8n 镜像,设置健康检查和重启策略;
- 数据:PoC 可用持久化卷,生产按规模评估 PostgreSQL;
- 凭据:固定且安全保存的
N8N_ENCRYPTION_KEY,与数据库一起备份; - 执行:设置超时、并发、执行数据保留和二进制文件生命周期;
- 运维:日志、可用性、失败工作流、资源、证书和备份恢复监控。
n8n 官方维护Docker Compose 服务器部署示例和自托管安全文档。版本、变量和示例会变化,部署时应从官方页面取得当前文件,不从旧文章复制整份 Compose。
第一步:准备 VPS、域名和最小端口
- 按工作流并发、单次数据量、二进制文件和保留期确定 PoC 规格;
- 选择靠近主要 API、内部系统或运营团队的节点,而不是默认某个国家;
- 安装当前受支持的 Docker Engine 与 Compose 插件;
- 为 n8n 建立独立目录和运维账号,不长期用 root 运行日常操作;
- 将域名解析到 VPS,防火墙只允许管理来源访问 SSH,并开放 80/443;
- 不要把 5678 直接开放给整个互联网,反向代理从内部网络访问容器。
地域与线路先按业务选择服务器节点和测试 IP 验证线路完成。主机上线前执行VPS 安全设置清单。
第二步:从官方 Compose 建立配置
下载官方当前示例后,至少逐项确认:
| 配置项 | 用途 | 常见错误 |
|---|---|---|
N8N_HOST / 协议 / 端口 |
生成正确的外部地址 | 仍使用 IP 或 HTTP,导致 OAuth 回调不一致 |
WEBHOOK_URL |
让外部服务回调正确域名 | 写成容器地址或漏掉 HTTPS |
N8N_PROXY_HOPS |
让 n8n 正确识别受信代理链 | 数量与真实代理层不一致 |
N8N_ENCRYPTION_KEY |
加密保存凭据 | 每次重建随机变化或没有备份 |
| 时区设置 | 定时器和日志使用业务时区 | 服务器、容器和工作流时区混乱 |
| 数据库与持久化卷 | 保存工作流、凭据和执行数据 | 只备份容器,没有备份数据 |
生成密钥时不要把真实值写入命令历史、工单或 Git。将 .env 权限限制给部署账号,并使用组织已有的秘密管理方案。旧教程中的 N8N_BASIC_AUTH_ACTIVE、示例管理员密码和直接访问 http://IP:5678 不应继续作为当前上线方案。
第三步:启动、创建所有者并做入口验收
docker compose pull
docker compose config
docker compose up -d
docker compose ps
docker compose logs --tail=200 n8n
docker compose config 用于发现语法和变量问题,但输出可能包含展开后的敏感值,不要公开粘贴。首次访问时创建实例所有者,启用可用的多因素认证,并确认:
- HTTP 会重定向到 HTTPS,证书链和续期正常;
- 从公网不能直接连接 5678 和数据库端口;
- 错误密码、未登录会话和无权限用户无法进入管理界面;
- 编辑器 URL、测试 webhook 与生产 webhook 都使用正确域名;
- 重启容器和 VPS 后,账号、凭据与工作流仍存在。
OpenAI、Gemini 等 AI 服务怎样安全接入?
- 在模型供应商后台创建专用项目或服务凭据,不复用个人主密钥;
- 设置能设置的额度、模型权限、来源和告警;
- 在 n8n 的 Credentials 中创建凭据,优先使用当前内置节点;
- HTTP Request 节点只在内置节点不满足时使用,端点和字段以供应商当前官方文档为准;
- 测试数据先脱敏,不把客户数据、密码或完整日志直接发送给模型;
- 对生成内容加格式校验、预算上限、超时、重试和人工复核。
API 密钥不要放在查询参数、节点名称、Code 节点源码或导出的工作流 JSON 中。模型名、价格、配额和接口版本会变化,不应在部署文章中承诺固定可用。
工作流上线前的业务验收
| 测试 | 通过标准 |
|---|---|
| 重复 webhook | 相同事件不会重复创建订单、线索或付款 |
| 外部 API 超时/429/5xx | 按上限退避重试,失败进入可追踪队列 |
| 凭据失效 | 告警到责任人,能安全轮换且不丢工作流 |
| 大文件或大批量 | 内存、磁盘和执行时间不超过已批准阈值 |
| 人工复核 | 高风险动作在付款、删除、群发前等待批准 |
| 重启和恢复 | 未完成任务状态可解释,数据库与凭据可恢复 |
备份、清理、监控与更新
- 备份数据库、持久化文件、加密密钥、Compose 配置和反向代理配置;
- 按官方执行数据文档设置保留与清理,避免数据库无限增长;
- 监控 HTTPS、容器、数据库、CPU、内存、磁盘、失败执行和 webhook 错误率;
- 定期运行官方支持的
n8n audit,检查实例、凭据、节点和 webhook 风险; - 升级前固定目标版本、阅读发布说明、备份并在测试环境验证;
- 保留旧镜像与数据库恢复点,出现迁移问题时按批准的回退方案处理。
完整恢复流程可参考云服务器备份与恢复指南,监控方法见网站、应用与主机监控指南。
服务器怎样采购?
先用代表性工作流运行 7 天,记录并发执行、单次峰值内存、执行数据增长、二进制文件、数据库时延和外部 API 时间,再决定扩容。可在萤光云海外 VPS 节点列表核对当前地域和配置;库存、价格和线路以实时产品页与控制台为准。服务器只能提供运行环境,n8n 架构、工作流正确性、第三方 API 许可和数据合规仍由使用方负责。
常见问题
n8n 必须用 4 核 8GB 吗?
不是。简单低频工作流可能更小,AI、大文件、高并发和长执行可能需要更多资源;以代表性负载和监控决定。
可以直接开放 5678 吗?
不建议。生产环境应通过 HTTPS 入口访问,并在网络层阻止公网直接连接应用端口。
只备份 n8n 数据库够吗?
通常不够。还需要加密密钥、持久化文件或二进制数据、配置、代理和恢复说明;缺少原加密密钥可能无法解密凭据。
接入 AI API 后能自动处理所有业务吗?
不能。模型输出和外部 API 都可能失败,高风险动作需要确定性校验、权限限制和人工审批。







