n8n 本地部署：比装起来更重要的是凭据、权限和许可
n8n 自托管的部署门槛不算高，官方文档写得清楚。所以这篇不重复讲部署步骤——讲装好之后必须处理的四件事。
这四件事不处理，你会在几个月后以某种难受的方式想起它们。
具体的部署方式、环境变量和配置项请以 n8n 官方文档为准，会随版本变化。这篇讲的是部署之外的决策。
零、先过许可这一关
放在最前面，因为这条不通过，后面都白说。
n8n 用的是 Sustainable Use License，官方自称 fair-code，不自称开源。 核心限制两条：
- 只允许用于你自己的内部业务目的，或非商业、个人用途
- 分发或提供给别人，必须免费且非商业
另外仓库里文件名或目录名带 .ee 标记的部分是企业版代码，走独立的企业许可。
结论很直接：
- 自己团队内部搭流程、做内部提效 → 没问题，放心用
- 部署到甲方环境作为项目交付物收费 → 很可能超出许可范围，别默认「开源随便用」
如果你是系统集成商，这条几乎决定了 n8n 在你的方案里能不能出现。可自部署的替代方案里，Dify 和 FastGPT 的许可明确允许交付给企业，LangFlow 是标准 MIT。详细对比见开源 Agent 平台的许可证差别。
这段是提示不是法律意见，商用前请自己读官方 LICENSE。
一、凭据管理：这是自托管最大的安全面
n8n 的价值在于连接一切，代价是它手里握着连接一切所需的钥匙：数据库密码、各种服务的 API key、邮箱账号、内部系统的访问凭据。
这些东西集中在一个地方，意味着这台机器的安全等级应该按「最敏感的那个凭据」来定，而不是按「一个自动化工具」来定。
要处理的几件事：
加密配置。 n8n 对存储的凭据有加密机制，涉及一个加密密钥。这个密钥丢了，已存的凭据就解不开了；这个密钥泄露了，凭据的加密就形同虚设。它需要被当作核心机密来备份和保管，具体配置方式见官方文档。
最小权限原则。 给 n8n 的数据库账号、API key，权限能小就小。它需要读某张表就只给读那张表的权限，别图省事给管理员账号——一旦出事，影响范围完全不同。
定期清理。 试验时创建的凭据、离职同事配的账号，记得清。
二、访问控制：谁能看、谁能改
自托管的默认状态往往是「能访问这个地址的人就能改所有流程」。这在个人使用时没问题，团队使用时是隐患。
要想清楚三件事：
谁能访问这个地址。 最简单有效的办法是别把它直接暴露在公网——放内网，或者加一层网络层面的访问控制。这比任何应用层的权限设置都可靠。
谁能修改流程。 一个正在跑生产任务的流程，被人随手改了一个节点，可能要过几天才被发现。至少要做到「谁改的」可追溯。
谁能看执行记录。 执行记录里会留下流程处理过的数据。如果流程处理的是客户信息、订单数据，那执行记录的敏感程度等同于业务数据本身。
三、Webhook 暴露面
如果你用了 Webhook 触发，那就意味着有一个公网可访问的入口能触发你的流程。
这个入口需要验证。 不能只靠 URL 难猜——URL 会出现在日志里、会被同事复制粘贴到聊天工具里、会留在浏览器历史里。
要考虑被重复调用的情况。 同一个请求发两次，你的流程会执行两次吗？如果这个流程会发消息、会写数据、会花钱，重复执行的后果要提前想清楚。
要考虑被恶意调用的情况。 有人拿到了这个地址，高频调用会怎么样？至少不能让它把你的模型调用额度刷光。
四、失败了谁知道
这是自托管最容易忽略的一条：定时任务默默失败，没有人知道。
托管服务通常会给你发通知。自托管的话，这套机制要自己建：
失败要有告警。 流程执行失败，得有人收到消息。最低限度是发到一个大家会看的群里。
要能看出「没跑」。 比失败更隐蔽的是根本没触发——服务挂了、容器没起来、定时配置被改了。这种情况不会产生失败记录，因为压根没执行。需要一个「预期该跑却没跑」的检查。
执行记录要有保留策略。 记录会一直增长，占磁盘。但也不能不留，出问题时要靠它排查。定一个保留期限。
五、把流程本身当代码来管
这一条不是安全问题，是长期维护问题，但代价一样大。
流程会被改，而且往往没人记得改了什么。 三个月后有人问「这个流程为什么这么设计」，没人答得上来；出了问题想回退到上一个版本，回不去。
几个成本很低但有用的做法：
定期导出流程定义存档。 n8n 的流程可以导出成结构化文件。定期导出、存到版本管理里，等于给自己留了后路。真出问题时能对比出改了什么。
给流程写说明。 至少写清楚：这个流程干什么、谁在用、失败了找谁、依赖哪些外部系统。写在流程的备注里或者单独的文档里都行，关键是别只存在某个人的脑子里。
区分生产流程和试验流程。 用命名或者分组把它们分开。最怕的是有人以为在改试验流程，实际改的是正在跑的生产流程。
离职交接要包含流程清单。 自动化流程有个特点：跑得好的时候完全没有存在感。等到唯一懂它的人走了、它又出了问题，才发现没人知道它在干什么。
部署形态怎么选
单机容器 —— 大多数内部使用场景够了。简单，好维护。
加独立数据库 —— 执行记录多了之后，默认的存储方式可能不够用。这一步升级通常比想象中来得早。
队列模式 —— 任务量大、需要并发处理时才需要。别一上来就上，复杂度会立刻翻倍。
判断标准：先用最简单的跑起来，遇到瓶颈再升级。提前架构的成本，通常花在了永远不会到来的规模上。
一个务实的推进顺序
- 先在测试环境装一套，跑通一个真实流程
- 把凭据管理和加密密钥备份的方案定下来
- 决定访问控制方式（强烈建议先放内网）
- 建告警通道
- 再考虑正式启用
第 2 步和第 4 步是最容易被跳过、也最容易在半年后让人后悔的两步。
如果你的场景是要交付给客户、而不是内部使用，那第一步应该是回到许可这一条重新选型。判断标准见低代码 Agent 平台的能力边界，或者直接找我们聊。